Governance für Vereinbarungen zur Datenweitergabe nach GDPR und ISO 27701

Es ist Dienstag, 16:00 Uhr, und Sarah, CISO eines schnell wachsenden FinTech-Unternehmens, prüft eine Vereinbarung zur Datenweitergabe mit einem strategischen KI-Analysepartner. Der Vertrieb ist begeistert. Der Partner verspricht bessere Kundeneinblicke, stärkere Personalisierung und schnellere Abwanderungsprognosen. Die Rechtsabteilung ist vorsichtig. Die Vereinbarung enthält vage Formulierungen wie „wirtschaftlich angemessene Sicherheit“ und sagt nahezu nichts zu Fristen für die Reaktion auf Informationssicherheitsvorfälle, zur Bearbeitung von Betroffenenrechten, zur Aufbewahrung, Löschung, zu Auditrechten oder zur Exit-Planung.

Sarah erkennt das Risiko sofort. Handelt der Partner als Auftragsverarbeiter, als eigenständiger Verantwortlicher oder als gemeinsam Verantwortlicher? Wer validiert die Rechtsgrundlage nach GDPR? Wenn ein Kunde einen Löschantrag stellt, welcher Prozess stellt sicher, dass die Daten aus der Partnerumgebung, aus abgeleiteten Datenbeständen und, soweit anwendbar, aus KI-Trainingspipelines gelöscht werden? Wenn der Partner eine Verletzung des Schutzes personenbezogener Daten erleidet, wer informiert wen, wann und mit welchen Nachweisen?

Das ist nicht nur ein schlechter Vertrag. Es ist ein versagendes Betriebsmodell.

Moderne SaaS-, FinTech-, Healthtech-, Managed-Service- und Plattformunternehmen geben fortlaufend Daten über Programmierschnittstellen, Integrationen, Analysepartnerschaften, Support-Tools, Cloud-Plattformen, verbundene Unternehmen, Ersuchen öffentlicher Stellen und KI-Services weiter. Die kommerzielle Sprache entwickelt sich häufig schneller als die Governance. Ein Vertrag wird unterzeichnet, ein API-Token wird ausgegeben, und personenbezogene Daten beginnen zu fließen, bevor Datenschutz, Sicherheit, Beschaffung, Engineering und der DPO die Grundlagen abgestimmt haben.

Unter GDPR ist eine Vereinbarung zur Datenweitergabe nicht nur ein rechtliches Artefakt. Sie ist Nachweis für Rechtmäßigkeit, Fairness, Transparenz, Zweckbindung, Datenminimierung, Speicherbegrenzung, Integrität, Vertraulichkeit und Rechenschaftspflicht. Unter ISO/IEC 27701:2025 wird sie Teil eines Privacy Information Management System (PIMS), mit dem die Organisation nachweisen kann, dass personenbezogene Informationen über gesteuerte Prozesse erhoben, verwendet, offengelegt, weitergegeben, aufbewahrt, geschützt und entsorgt werden.

Clarysec behandelt Governance für die Datenweitergabe als funktionsübergreifendes Kontrollsystem, nicht als Übung zum Ausfüllen von Vertragsvorlagen. Mit dem Zenith Blueprint, Zenith Controls und dem PIMS-Richtlinienset von Clarysec können Organisationen von Ad-hoc-Vertragsprüfungen zu einem auditbereiten Lebenszyklus übergehen, der rechtliche Klauseln, Register, Risikoentscheidungen, technische Kontrollen und Compliance-Nachweise miteinander verbindet.

Warum Vereinbarungen zur Datenweitergabe in echten Audits scheitern

Die meisten Organisationen scheitern nicht daran, dass sie nie einen Vertrag erstellt haben. Sie scheitern daran, dass der Vertrag von der operativen Realität getrennt ist.

Ein Datenschutzprüfer fordert das Register zur Datenweitergabe an. Die Rechtsabteilung sendet die unterzeichnete Vereinbarung. Anschließend fragt der Prüfer nach Rechtsgrundlage, Offenlegungszweck, Empfängerrolle, PII-Kategorien, Aufbewahrungsregel, Verarbeitungsort, Übermittlungsverfahren, Routing für Betroffenenanfragen, technischen Schutzmaßnahmen und Nachweisen zur Überprüfung. Plötzlich ist die unterzeichnete Vereinbarung nur noch ein Teil des Gesamtbilds.

GDPR Article 5 verlangt, dass die Verarbeitung personenbezogener Daten den Grundsätzen Rechtmäßigkeit, Fairness, Transparenz, Zweckbindung, Datenminimierung, Richtigkeit, Speicherbegrenzung sowie Integrität und Vertraulichkeit folgt. Article 5(2) ergänzt die Rechenschaftspflicht; der Verantwortliche muss also die Einhaltung nachweisen können. Article 6 verlangt eine gültige Rechtsgrundlage. Article 9 legt für besondere Kategorien personenbezogener Daten, einschließlich Gesundheitsdaten, biometrischer Daten, genetischer Daten, politischer, religiöser und anderer sensibler Kategorien, einen höheren Maßstab an.

In der Praxis muss ein Governance-Prozess für Vereinbarungen zur Datenweitergabe diese Fragen beantworten, bevor eine wiederkehrende externe Weitergabe beginnt:

• Wer ist der Empfänger, und welche Datenschutzrolle hat er?
• Welche personenbezogenen Daten werden weitergegeben, und zu welchem Zweck?
• Welche Rechtsgrundlage stützt die Offenlegung?
• Ist der neue Zweck mit dem ursprünglichen Erhebungszweck vereinbar?
• Wurden die betroffenen Personen über einen Datenschutzhinweis oder einen anderen Transparenzmechanismus informiert?
• Welche Register, Genehmigungen und Risikoentscheidungen belegen die Weitergabe?
• Wie werden Betroffenenanfragen zwischen den Parteien geroutet?
• Welche Pflichten zu Aufbewahrung, Löschung, Rückgabe und Beendigung gelten?
• Welche Schutzmaßnahmen sichern Übermittlung, Speicherung, Zugriff, Protokollierung, nachgelagerte Offenlegung und Auditierbarkeit ab?
• Was geschieht, wenn der Partner Zweck, Standort, Subunternehmer oder Datenkategorien ändert?

Der Zenith Blueprint, Phase „Controls in Action“, Step 23, beschreibt die Auditrealität klar:

Die Grundlage dieser Kontrolle ist Datenbewusstsein. Die Organisation muss wissen, welche PII sie erhebt, wo diese liegen, warum sie verarbeitet werden und wer darauf zugreifen kann. Ohne diese Basis sind alle Datenschutzversprechen leer. Klassifizierung und Kennzeichnung (5.12–5.13) werden hier wesentlich, denn PII können nicht geschützt werden, wenn sie nicht identifiziert sind.

Wenn die Vereinbarung nicht mit Inventar, Klassifizierung, Aufbewahrung, Sicherheitskontrollen und dem Prozess für Betroffenenrechte verknüpft ist, handelt es sich nicht um Governance. Es ist ein Dokument in einem Repository.

Datenweitergabe ist nicht dasselbe wie Verarbeitung im Auftrag eines Kunden

Ein häufiger Fehler besteht darin, jede Drittparteienbeziehung mit personenbezogenen Daten als Auftragsverarbeitungsszenario zu behandeln. GDPR verlangt eine Rollenanalyse. Ein Auftragsverarbeiter handelt im Auftrag eines Verantwortlichen. Ein Verantwortlicher bestimmt Zwecke und Mittel. Gemeinsam Verantwortliche bestimmen Zwecke und Mittel gemeinsam. Einige Empfänger sind eigenständige Verantwortliche, die Daten für eigene Zwecke erhalten.

Diese Unterscheidung verändert das Vereinbarungsmodell.

Ein Auftragsverarbeitungsvertrag konzentriert sich auf dokumentierte Weisungen, Vertraulichkeit, Unterauftragsverarbeiter, Unterstützung, Sicherheit, Meldung von Datenschutzverletzungen, Löschung oder Rückgabe und Auditunterstützung. Eine Vereinbarung zur Datenweitergabe zwischen Verantwortlichen fokussiert stärker auf Rechtsgrundlage, Zweck, Transparenz, Unabhängigkeit des Empfängers, Grenzen nachgelagerter Offenlegung, Koordination von Betroffenenrechten, Aufbewahrung, Sicherheitsmaßnahmen und Zuweisung von Verantwortlichkeiten. Eine Vereinbarung über gemeinsame Verantwortlichkeit erfordert eine transparente Zuweisung von Pflichten und Klarheit über die gemeinsame Entscheidungsfindung.

Die PIMS-Richtlinien von Clarysec machen diese Klassifizierung zu einem verpflichtenden Gate. Die Enterprise-Processor, Subprocessor and Third-Party Privacy Management Policy legt fest:

[Both] Der Privacy Lead / PIMS Manager MUSS jede datenschutzbezogene Drittparteienbeziehung als Verantwortlicher, gemeinsam Verantwortlicher, Auftragsverarbeiter, Unterauftragsverarbeiter oder sonstige Drittparteienbeziehung in REG08 klassifizieren, bevor die Vertragsfreigabe erfolgt oder bevor die PII-Verarbeitung beginnt, je nachdem, was zuerst eintritt.

Für SMEs wird derselbe Grundsatz einfacher ausgedrückt. Die Data Protection and Privacy Policy - SME, Governance Requirements 5.2.2, verlangt:

Verträge mit Dritten, die personenbezogene Daten verarbeiten, müssen Datenschutzklauseln enthalten und vom General Manager (GM) oder Rechtsberater geprüft werden.

Die praktische Lehre lautet: Klassifizieren Sie die Beziehung, bevor Klauseln formuliert werden. Die Rolle bestimmt Vereinbarung, Genehmigungen, Schutzmaßnahmen, Verantwortlichkeiten und Nachweise.

Der Governance-Lebenszyklus für Datenweitergabe

Ein ausgereifter Workflow für Vereinbarungen zur Datenweitergabe muss sich wie ein kontrollierter Geschäftsprozess anfühlen, nicht wie eine rechtliche Notfalleskalation. Clarysec setzt ihn typischerweise über sieben miteinander verbundene Gates um.

Die Enterprise-PII Collection, Use, Disclosure and Sharing Policy macht die Anforderung auf Verantwortlichenseite ausdrücklich:

[Controller] Der Vendor / Procurement Owner MUSS Empfängeridentität, Empfängerrolle, Offenlegungszweck, PII-Kategorien, Weitergabefrequenz, Verarbeitungsort und maßgebliche Quelle in REG08 erfassen, bevor wiederkehrende externe Weitergabe beginnt.

REG08 ist das Register für Empfänger und datenschutzbezogene Drittparteienbeziehungen. Es darf nicht getrennt vom Verarbeitungsinventar geführt werden. Die Enterprise-PII Processing Inventory and Lawful Basis Policy verlangt:

[Both] Der Vendor / Procurement Owner MUSS vor Vertragsfreigabe oder wesentlicher Änderung der Beziehung verifizieren, dass Einträge zu externen Empfängern, Auftragsverarbeitern, Unterauftragsverarbeitern und Datenweitergaben in REG02 mit REG08 übereinstimmen.

Damit wird eine häufige Auditlücke geschlossen. REG02 kann „Produktanalysen zur internen Verbesserung“ enthalten, während REG08 „Analysepartner für Benchmarking“ nennt. Wenn Zweck, Empfänger, Rechtsgrundlage, Datenkategorien oder Aufbewahrungsregeln nicht übereinstimmen, hat die Organisation ein Defizit in der Rechenschaftspflicht.

Was jede Vereinbarung zur Datenweitergabe enthalten sollte

Eine Vereinbarung zur Datenweitergabe nach GDPR und ISO 27701:2025 darf sich nicht auf generische Vertraulichkeitsformulierungen verlassen. Sie muss den tatsächlichen Datenfluss, die Rollenklassifizierung, das Risikoprofil und die operativen Schnittstellen widerspiegeln.

Der Zenith Blueprint, Phase „Controls in Action“, Step 23, liefert die Perspektive auf Lieferantenvereinbarungen:

Wesentliche Bereiche, die typischerweise in Lieferantenvereinbarungen adressiert werden, sind:

✓ Vertraulichkeitspflichten, einschließlich Geltungsbereich, Dauer und Beschränkungen für Offenlegungen gegenüber Dritten; ✓ Verantwortlichkeiten für die Zugriffskontrolle, etwa wer auf Ihre Daten zugreifen darf, wie Zugangsdaten verwaltet werden und welche Überwachung besteht; ✓ technische und organisatorische Maßnahmen für Datenschutz, Verschlüsselung, sichere Übertragung, Backup und Verfügbarkeitszusagen; ✓ Fristen und Protokolle für die Meldung von Vorfällen, häufig mit definierten Zeitrahmen (z. B. „Benachrichtigung innerhalb von 24 Stunden“); ✓ Auditrechte, einschließlich Häufigkeit, Geltungsbereich und Zugriff auf relevante Nachweise (z. B. Berichte zu Penetrationstests, SoA, Zertifizierungen); ✓ Kontrollen für Subunternehmer, die den Lieferanten verpflichten, gleichwertige Sicherheitsverpflichtungen an seine nachgelagerten Partner weiterzugeben; ✓ Regelungen zum Vertragsende, etwa Datenrückgabe oder Vernichtung, Asset-Wiederherstellung und Kontodeaktivierung.

Enterprise-Rechtsgovernance verstärkt diesen Punkt. Die Legal and Regulatory Compliance Policy, Governance Requirements 5.3.1.2, nennt Verträge, die Folgendes betreffen:

Verträge, die Datenweitergabe, Rechte an geistigem Eigentum, Haftungsbeschränkungen oder Auditklauseln betreffen

Damit liegt Governance für Datenweitergabe an der Schnittstelle von Datenschutz, Recht, kommerziellem Risiko, Lieferantensicherung und Sicherheitsbetrieb.

Klassifizierung und sichere Übermittlung sind die fehlende Brücke

Viele Fehler bei der Datenweitergabe beginnen mit mangelhafter Klassifizierung. Wenn der Geschäftsinhaber nicht angeben kann, ob der Datenbestand öffentlich, intern, vertraulich oder streng vertraulich ist oder regulierte PII enthält, bleibt die Vereinbarung vage und die technischen Kontrollen werden uneinheitlich.

Clarysecs Data Classification and Labeling Policy - SME legt fest:

Vereinbarungen zur Datenweitergabe oder Geheimhaltungsvereinbarungen (NDAs) müssen auf Anforderungen zur klassifizierungsgerechten Handhabung verweisen.

Für Enterprise-Umgebungen verlangt die Data Classification and Labeling Policy, dass bestimmte Daten:

Nur unter einem NDA oder gleichwertigen vertraglichen Schutzmaßnahmen extern weitergegeben werden dürfen

Die Klassifizierungskennzeichnung sollte in der Vereinbarung oder im Sicherheitsanhang erscheinen. Wenn die Support-Ticket-Historie als vertraulich klassifiziert ist und PII enthält, sollte die Vereinbarung zulässige Empfänger, genehmigte Übermittlungsverfahren, Speicherorte, Zugriffskontrollen, Überwachung, Erwartungen an die Löschung und Nachweise der Sicherstellung definieren.

Der Zenith Blueprint, Phase „Controls in Action“, Step 22, erläutert die operative Seite der Informationsübermittlung:

Im Kern verlangt diese Kontrolle, dass die Organisation:

✓ definiert, wie Informationen intern und extern übertragen werden dürfen; ✓ festlegt, welche Verfahren zulässig sind (z. B. verschlüsselte E-Mail, sichere Portale, SFTP, APIs, physische Lieferung mit Verschlüsselung); ✓ Übermittlungsverfahren an der Informationsklassifizierung ausrichtet (wie in 5.12 definiert und über 5.13 sichtbar gemacht); ✓ und sicherstellt, dass alle an der Übermittlung beteiligten Parteien ihre Rollen, Verantwortlichkeiten und Verpflichtungen verstehen.

Für SMEs formuliert die Third-Party and Supplier Security Policy - SME die Erwartung direkt:

Alle mit Lieferanten geteilten Daten müssen durch Verschlüsselung geschützt und über sichere Protokolle übertragen werden (z. B. HTTPS, SFTP).

Enterprise-Lieferantengovernance ergänzt weitere Details. Die Third party and supplier security policy verlangt Datenverarbeitungsanforderungen einschließlich:

Datenverarbeitungsanforderungen, einschließlich Speicherort, Zugriffskontrollen sowie Klauseln zur Rückgabe oder Vernichtung

Diese Anforderungen dürfen nicht in einem Fragebogen verborgen sein. Sie müssen als Vertragsbedingungen durchsetzbar und auf REG08, technische Konfiguration und Auditnachweise zurückführbar sein.

Beispiel: Genehmigung von Sarahs KI-Analysepartner

Sarahs FinTech-Unternehmen möchte pseudonymisierte Kundenkennungen, Transaktionsmuster, Nutzungskennzahlen und Informationen zur Support-Stufe mit einem KI-Analysepartner zur Personalisierung und Abwanderungsprognose teilen. Der Partner kann die Daten mit seinen Analysemodellen kombinieren und Erkenntnisse an das FinTech zurückliefern.

Ein gesteuerter Workflow sähe so aus.

Zuerst erstellt der Vendor oder Procurement Owner den REG08-Eintrag. Der Privacy Lead oder PIMS Manager klassifiziert die Beziehung. Wenn der Partner Analysezwecke und Modelldesign über Sarahs Weisungen hinaus bestimmt, kann die Rolle eher eigenständiger Verantwortlicher oder gemeinsam Verantwortlicher als Auftragsverarbeiter sein.

Zweitens wird REG02 abgeglichen. Wenn das Verarbeitungsinventar nur „interne Produktanalyse“ beschreibt, muss es vor Beginn der externen Weitergabe aktualisiert werden. Die Rechtsgrundlage muss dokumentiert werden, und wenn sich der Zweck geändert hat, kann eine Vereinbarkeitsprüfung oder Prüfung des berechtigten Interesses erforderlich sein.

Drittens wendet der Dateneigentümer Klassifizierung und Datenminimierung an. E-Mail-Domains von Administratoren sind möglicherweise nicht erforderlich. Konto-Kennungen können durch partnerspezifische pseudonyme Kennungen ersetzt werden. Die Support-Stufe darf nur beibehalten werden, wenn sie für den genehmigten Zweck erforderlich ist.

Viertens verhandeln Recht, Datenschutz und Sicherheit die Vereinbarung zur Datenweitergabe und den Sicherheitsanhang. Die Vereinbarung verbietet Re-Identifizierung, beschränkt nachgelagerte Offenlegung, definiert Aufbewahrung, verlangt Löschungsnachweise, legt Fristen für die Vorfallmeldung fest, enthält Audit- oder Sicherstellungsrechte und definiert Exit-Schritte.

Fünftens werden der Datenschutzhinweis und der Workflow für Betroffenenrechte aktualisiert. Die Enterprise-PII Principal Rights Management Policy verlangt:

[Both] Der Vendor / Procurement Owner MUSS die Bestätigung von Dritten zu rechtsbezogenen Benachrichtigungen in REG08 nachverfolgen, bevor die zugehörige REG06-Anfrage geschlossen wird.

Für SMEs gibt die Data Protection and Privacy Policy - SME eine praktische Service-Level-Erwartung vor:

Der Datenschutzkoordinator muss Anfragen innerhalb von 3 Arbeitstagen bestätigen und innerhalb von 30 Tagen beantworten.

Schließlich setzt Engineering die Vereinbarung technisch durch. API-Zugangsdaten werden auf den erforderlichen Umfang beschränkt. Übermittlungen nutzen HTTPS. Protokolle erfassen Datenabrufe. Warnmeldungen erkennen ungewöhnliche Aktivitäten. Zugriffe werden überprüft. Aufbewahrung wird, wo möglich, automatisiert. Die Vereinbarung wird zu einem lebenden Kontrollsystem, nicht zu einer PDF-Datei.

Cross-Compliance-Zuordnung für GDPR, ISO 27701, DORA, NIS2, NIST und COBIT 19

Governance für Datenweitergabe gehört selten nur zu einem Rahmenwerk. Sie berührt GDPR-Rechenschaftspflicht, Datenschutzprozesse nach ISO/IEC 27701:2025, Anforderungen an Managementsysteme nach ISO/IEC 27001:2022, Sicherheitskontrollen nach ISO/IEC 27002:2022, DORA-Drittparteienrisiko, NIS2-Sicherheit der Lieferkette, Ergebnisse nach NIST CSF 2.0 und Governance-Erwartungen nach COBIT 19.

ISO/IEC 27001:2022 clause 4.2 verlangt, dass Organisationen interessierte Parteien und deren relevante Anforderungen verstehen. Clause 5.1 verlangt, dass die Leitung Informationssicherheitsanforderungen in Geschäftsprozesse integriert. Für Datenweitergabe bedeutet dies, dass Partnerabhängigkeiten, vertragliche Anforderungen, regulatorische Verpflichtungen und Risikoentscheidungen innerhalb von ISMS und PIMS liegen müssen, nicht außerhalb.

Die relevantesten ISO/IEC 27002:2022-Kontrollen sind:

• 5.14 Information transfer
• 5.20 Addressing information security within supplier agreements
• 5.34 Privacy and protection of PII

Zenith Controls unterstützt Organisationen dabei, diese Kontrollen als Zuordnungsanker zu nutzen. Es verknüpft ISO/IEC 27002:2022 control 5.14 mit dem Schutz von Daten während der Übertragung und vertraglichen Anforderungen, einschließlich NIST CSF 2.0 PR.DS-02 und GV.SC-05, DORA Article 30(2)(d) und GDPR Article 46, soweit geeignete Garantien für internationale Übermittlungen relevant sind. Es verknüpft control 5.20 mit Governance für Lieferantenvereinbarungen, einschließlich NIS2 Article 21(2)(d) Sicherheit der Lieferkette und DORA Chapter V zu IKT-Drittparteienrisiken. Es verknüpft control 5.34 mit Datenschutz und Schutz von PII, einschließlich GDPR Article 5(2) Rechenschaftspflicht und unterstützenden Kontrollen wie Verschlüsselung, Löschung, Lieferantenmanagement und Zweckbindung.

Das Ziel sind nicht sieben Compliance-Programme. Das Ziel ist ein gesteuerter Lebenszyklus für Datenweitergabe, der wiederverwendbare Nachweise erzeugt.

Wie Auditoren Ihre Vereinbarungen zur Datenweitergabe prüfen werden

Ein belastbarer Governance-Prozess muss Stichprobenprüfungen standhalten. Auditoren bleiben nicht bei der unterzeichneten Vereinbarung stehen. Sie prüfen den Lebenszyklus.

Ein Auditor für ISO/IEC 27001:2022 und ISO/IEC 27701:2025 wird fragen, ob der ISMS- und PIMS-Geltungsbereich externe Weitergaben einschließt, ob die Risikobeurteilung die Beziehung abdeckt, ob Kontrollen ausgewählt und betrieben wurden und ob die Managementbewertung Drittparteienrisiken in Datenschutz und Sicherheit überprüft.

Ein GDPR-Prüfer oder eine Aufsichtsbehörde wird sich auf Rechenschaftspflicht konzentrieren. Er oder sie wird fragen, welche personenbezogenen Daten weitergegeben wurden, warum, auf welcher Rechtsgrundlage, ob die betroffenen Personen informiert wurden, wie lange Daten aufbewahrt wurden, ob besondere Kategorien personenbezogener Daten betroffen waren, ob internationale Übermittlungen bewertet wurden und ob Betroffenenanfragen geroutet und nachgewiesen wurden.

Ein DORA-Prüfer, insbesondere im Finanzsektor, wird fragen, ob die Vereinbarung eine kritische oder wichtige Funktion unterstützt, ob sie im IKT-Vertragsregister enthalten ist, ob der Vertrag Unterstützung bei Vorfällen, Auditrechte, Datenstandort, Bedingungen für Unterauftragsvergabe, Kündigungsrechte und getestete Exit-Planung enthält.

Ein NIST CSF 2.0-Assessor wird nach GOVERN-Ergebnissen im Lieferantenrisikomanagement, PROTECT-Ergebnissen bei Kontrollen für Daten während der Übertragung, RESPOND-Ergebnissen bei Vorfalls-Schnittstellen und RECOVER-Ergebnissen in Exit- und Kontinuitätsplanung suchen.

Ein COBIT 19- oder ISACA-orientierter Auditor wird sich auf Entscheidungsrechte, Risikobereitschaft, Nutzenrealisierung, Ressourcenoptimierung, Compliance-Verpflichtungen, Kennzahlen, Ausnahmen und kontinuierliche Verbesserung konzentrieren.

Wenn Ihr Team diese Nachweise nicht schnell zusammenstellen kann, ist der Prozess zu stark von individuellem Wissen abhängig.

Häufige Fallstricke in der Governance für Datenweitergabe

Clarysec sieht immer wieder fünf Fehlermuster.

Das erste ist die Verwechslung eines AVV mit einer Vereinbarung zur Datenweitergabe. Auftragsverarbeiterklauseln lösen keine Rechenschaftspflicht zwischen Verantwortlichen oder gemeinsam Verantwortlichen.

Das zweite ist schwache Registerhygiene. REG02 und REG08 widersprechen einander. Der Datenschutzhinweis verweist allgemein auf „Geschäftspartner“, aber das Verarbeitungsinventar enthält keinen passenden Offenlegungszweck.

Das dritte ist mangelhaftes Routing für Betroffenenrechte. Eine betroffene Person stellt einen Löschantrag, aber niemand weiß, welche Empfänger benachrichtigt werden müssen oder wie die Bestätigung nachverfolgt wird.

Das vierte ist generische Sicherheitssprache. „Angemessene Sicherheit“ reicht nicht aus. Die Vereinbarung sollte Übermittlungsverfahren, Verschlüsselung, Zugriffskontrollen, Protokollierung, Speicherort, Vorfallsfristen, Löschung und Sicherstellung spezifizieren.

Das fünfte ist das Ignorieren nachgelagerter Offenlegung. Moderne SaaS-Ökosysteme umfassen Cloud-Plattformen, KI-Services, Analyseanbieter, Support-Tools, Managed Provider, verbundene Unternehmen und öffentliche Stellen. Governance für Datenweitergabe muss nachgelagerte Offenlegungen kontrollieren, wenn sie die Rechenschaftspflicht betreffen.

Die Processor, Subprocessor and Third-Party Privacy Management Policy erfasst die operative Verknüpfung für Beziehungen mit Auftragsverarbeitern und Unterauftragsverarbeitern:

[Both] Der Vendor / Procurement Owner MUSS sicherstellen, dass Verträge mit Auftragsverarbeitern und Unterauftragsverarbeitern vor Genehmigung Datenschutzunterstützung, Sicherstellung der Sicherheit, eine Vorfalls-Schnittstelle über PII15, Rückgabe oder Löschung über PII10, Übermittlungsverknüpfung über PII13 sowie Audit- oder Sicherstellungszusammenarbeit enthalten.

Auch wenn es sich um eine Beziehung zwischen Verantwortlichen handelt, bleibt die Governance-Logik wertvoll: Datenschutzunterstützung, Sicherstellung der Sicherheit, Vorfalls-Schnittstelle, Übermittlungsverknüpfung, Rückgabe oder Löschung und Auditzusammenarbeit müssen bewusst gestaltet werden.

Praktische Checkliste für Ihre nächste Vereinbarung zur Datenweitergabe

Verwenden Sie diese Checkliste, bevor Sie eine wiederkehrende externe Weitergabe personenbezogener Daten genehmigen.

• Bestätigen Sie die Datenschutzrolle des Empfängers in REG08.
• Bestätigen Sie vor der Genehmigung, dass REG02 und REG08 übereinstimmen.
• Dokumentieren Sie Offenlegungszweck und Rechtsgrundlage.
• Prüfen Sie, ob ein neuer Zweck eine Vereinbarkeitsprüfung erfordert.
• Identifizieren Sie PII-Kategorien, Kategorien betroffener Personen und besondere Kategorien personenbezogener Daten.
• Wenden Sie Datenminimierung an und entfernen Sie nicht erforderliche Felder.
• Verweisen Sie in der Vereinbarung auf Anforderungen zur klassifizierungsgerechten Handhabung.
• Definieren Sie genehmigte Übermittlungsverfahren und Verschlüsselungsanforderungen.
• Spezifizieren Sie Erwartungen zu Zugriffskontrolle, Protokollierung, Überwachung und Speicherort.
• Weisen Sie Verantwortlichkeiten für Transparenz und Aktualisierungen von Datenschutzhinweisen zu.
• Definieren Sie Routing, Bestätigung, Nachverfolgung und Abschlussnachweise für Betroffenenrechte.
• Definieren Sie Nachweise zu Aufbewahrung, Löschung, Rückgabe und Beendigung.
• Beschränken Sie nachgelagerte Offenlegung und verlangen Sie Änderungsmitteilungen.
• Nehmen Sie Meldefristen für Vorfälle und Anforderungen an die Zusammenarbeit auf.
• Nehmen Sie Rechte auf Audit, Sicherstellung oder Nachweisprüfung auf.
• Planen Sie regelmäßige Überprüfungen und Auslöser für Neubewertungen.

Wo Clarysec ansetzt

Der Wert von Clarysec liegt nicht nur in Vorlagen. Er liegt in der Verbindung von Richtlinien, Registern, Nachweisen, Auditlogik und Cross-Compliance-Zuordnung.

Der Zenith Blueprint gibt Implementierungsteams einen 30-Schritte-Fahrplan, um Kontrollanforderungen in wirksame Praktiken zu überführen. Für Datenweitergabe unterstützt Step 22 Teams beim Entwurf von Regeln für Informationsübermittlung, während Step 23 Datenschutz, Lieferantenvereinbarungen, rechtliche Anforderungen, PII-Schutz und vertragliche Verpflichtungen verbindet.

Zenith Controls bietet den Cross-Compliance-Kompass. Für dieses Thema verknüpft es ISO/IEC 27002:2022 controls 5.34, 5.14 und 5.20 mit der übergeordneten Audit-Story: Datenschutz, Informationsübermittlung und Governance für Lieferantenvereinbarungen. Es hilft CISOs, DPOs, Compliance-Managern, Beschaffungsteams und Auditoren, dieselbe Sprache zu sprechen, wenn Erwartungen aus GDPR, ISO/IEC 27701:2025, ISO/IEC 27001:2022, NIS2, DORA, NIST CSF 2.0 und COBIT 19 zugeordnet werden.

Das PIMS-Richtlinienset von Clarysec liefert Organisationen anschließend die operativen Regeln: Datenschutzbeziehungen klassifizieren, Verarbeitungs- und Empfängerregister pflegen, Registerabgleich verifizieren, Rechtsgrundlage definieren, Betroffenenrechte managen, Lieferanten- und Drittparteienklauseln kontrollieren, klassifizierungsgerechte Handhabung durchsetzen und Nachweise aufbewahren.

Wenn Ihre Organisation personenbezogene Daten mit Partnern, Plattformen, verbundenen Unternehmen, öffentlichen Stellen, Analyseanbietern, KI-Services oder Teilnehmern des SaaS-Ökosystems teilt, beginnen Sie nicht mit dem Vertrag. Beginnen Sie mit Governance.

Nutzen Sie Zenith Blueprint: An Auditor’s 30-Step Roadmap, um Datenweitergabe in Ihren ISMS- und PIMS-Implementierungsplan einzubetten. Nutzen Sie Zenith Controls: The Cross-Compliance Guide, um ISO/IEC 27002:2022 controls 5.34, 5.14 und 5.20 gegenüber den Sicherstellungserwartungen aus GDPR, NIS2, DORA, NIST und COBIT zuzuordnen. Implementieren Sie anschließend Clarysecs PIMS-Richtlinien, einschließlich der PII Collection, Use, Disclosure and Sharing Policy, PII Processing Inventory and Lawful Basis Policy und Processor, Subprocessor and Third-Party Privacy Management Policy, damit jede Vereinbarung durch Register, Workflows, Schutzmaßnahmen und Nachweise abgesichert ist.

Die praktische nächste Maßnahme ist einfach: Wählen Sie Ihre drei externen Datenweitergabebeziehungen mit dem höchsten Risiko aus und prüfen Sie sie gegen REG02, REG08, Rechtsgrundlage, Routing für Betroffenenrechte, Übermittlungskontrollen, Aufbewahrung und Auditnachweise. Wenn die Nachweiskette bricht, kann Clarysec Ihnen helfen, sie in ein auditbereites Governance-Modell für Datenweitergabe umzubauen.