Governance für gemeinsam Verantwortliche: Audit-Leitfaden zu GDPR Article 26

Der Anruf kam an einem Dienstagmorgen. Für den CISO von CareConnect, einem schnell wachsenden MedTech-SaaS-Anbieter, war es der Moment, in dem sich die Lage grundlegend änderte.

Am anderen Ende der Leitung war der Leiter Compliance von MetroHealth, dem wichtigsten Krankenhauspartner. Ein Patient, der die gemeinsam betriebene Remote-Monitoring-Plattform nutzte, hatte einen Monat zuvor ein Auskunftsersuchen gestellt. Keine der beiden Organisationen hatte vollständig geantwortet. Jede ging davon aus, dass die andere zuständig sei.

Dann leitete die Rechtsabteilung eine zweite Nachricht weiter. Ein Junior-Entwickler bei CareConnect hatte versehentlich einen nicht kritischen API-Endpunkt offengelegt, der begrenzte Patientenkennungen enthielt. Das Problem schien eindämmbar, und das 72-Stunden-Meldefenster der GDPR für Datenschutzverletzungen war noch nicht abgelaufen. Aber dieselbe Frage blockierte beide Teams.

Wer informiert die Aufsichtsbehörde? Wer kommuniziert mit den Patienten? Wer ist für den Datenschutzhinweis verantwortlich? Wer validiert die Betroffenenanfrage? Wer dokumentiert die Entscheidung?

Die kommerzielle Vereinbarung regelte Servicegutschriften, Abrechnung, Haftungsobergrenzen und Meilensteine der Produkt-Roadmap detailliert. Zur operativen Realität der Governance gemeinsam Verantwortlicher nach GDPR Article 26 sagte sie fast nichts.

An dieser Stelle scheitern viele Partnerschaften. Das Problem ist nicht, dass Datenschutz-, Rechts-, Sicherheits- und Beschaffungsteams den Begriff „Vereinbarung zwischen gemeinsam Verantwortlichen“ noch nie gehört hätten. Das Problem ist, dass vor Beginn der Verarbeitung niemand nachweisen kann, wer für Transparenz, Rechtsgrundlage, Betroffenenrechte, Eskalation bei Datenschutzverletzungen, an Lieferanten weiterzugebende Verpflichtungen, Übermittlungen, Aufbewahrung, Nachweise und Kommunikation mit Aufsichtsbehörden verantwortlich ist.

GDPR definiert die Verpflichtung. ISO/IEC 27701:2025 gibt Datenschutzteams eine Managementsystem-Struktur. Die PIMS-Richtlinien von Clarysec, der Zenith Blueprint: 30-Schritte-Roadmap für Auditoren und Zenith Controls: Der Cross-Compliance-Leitfaden machen aus Article 26 auditbereite Betriebsnachweise.

Warum Governance für gemeinsam Verantwortliche scheitert, bevor es jemand bemerkt

Eine Beziehung gemeinsam Verantwortlicher liegt vor, wenn zwei oder mehr Parteien gemeinsam die Zwecke und Mittel der Verarbeitung personenbezogener Daten festlegen. Auslöser ist nicht die Formulierung im Vertrag. Entscheidend ist die Entscheidungsbefugnis.

Im Beispiel von CareConnect und MetroHealth stellt CareConnect die Plattform, Analysen, technische Architektur, Benutzeroberfläche und Datenflüsse bereit. MetroHealth bringt die Patientenbeziehung, den klinischen Kontext, das Servicemodell und die Patientendaten ein. Beide beeinflussen, warum personenbezogene Daten verarbeitet werden und wie die Verarbeitung funktioniert. Das unterscheidet sich deutlich von einem Anbieter, der lediglich eine Datenbank hostet oder Nachrichten auf dokumentierte Weisung versendet.

Dasselbe Muster findet sich bei Kampagnen zur finanziellen Gesundheit, eingebetteten Versicherungspartnerschaften, Online-Marktplätzen, Konsortien zur Betrugserkennung, vernetzten Gesundheitsplattformen, Treueprogrammen, Ökosystemen zur Identitätsprüfung und Analysekooperationen. Eine Bank, ein Versicherer und eine SaaS-Plattform können gemeinsam Zielsegmente, Profiling-Regeln, Konversionskennzahlen und Marketingkanäle festlegen. Ein Auftragsverarbeitungsvertrag löst dieses Problem nicht, wenn die Parteien tatsächlich gemeinsam Verantwortliche sind.

Die praktischen Fehler sind vorhersehbar:

1. Der Datenschutzhinweis sagt kaum mehr als „wir können Daten mit Partnern teilen“.
2. Das Verarbeitungsinventar benennt Parteien, aber nicht die Zuweisung der Pflichten.
3. Der Workflow für Betroffenenrechte enthält keinen Weg zur Weiterleitung, Validierung oder Beantwortung von Anfragen.
4. Der Vorfallplan sagt „Rechtsabteilung benachrichtigen“, aber nicht, welcher gemeinsam Verantwortliche die externe Kommunikation führt.
5. Der Vertrag wird als kommerzieller Schriftverkehr behandelt, nicht als Nachweis der Rechenschaftspflicht.
6. Beendigungsklauseln decken Rückgabe von Daten, Löschung, Anonymisierung, Entzug von Zugriffen oder Aufbewahrung von Nachweisen nicht ab.

GDPR Article 5 macht diese Fehler auditsensitiv, weil Verantwortliche Grundsätze wie Rechtmäßigkeit, Fairness, Transparenz, Zweckbindung, Datenminimierung, Richtigkeit, Speicherbegrenzung, Integrität, Vertraulichkeit und Rechenschaftspflicht nicht nur einhalten müssen. Sie müssen die Einhaltung auch nachweisen können. Article 6 ergänzt die Anforderung an die Rechtsgrundlage. Article 3 kann Nicht-EU-SaaS-, FinTech-, HealthTech- und Analyseanbieter in den Geltungsbereich bringen, wenn sie Personen in der EU Dienstleistungen anbieten oder deren Verhalten beobachten.

Die Lehre für CISOs und Compliance-Manager ist eindeutig: Governance für gemeinsam Verantwortliche ist nicht „nur Recht“. Sie ist ein funktionsübergreifendes Kontrollsystem mit Datenschutz, Sicherheit, Beschaffung, Produktmanagement, Engineering, Support, Incident Response, Marketing und Aufsicht durch die Geschäftsleitung.

Das ISO/IEC 27701:2025-PIMS-Prinzip: vor Beginn der Verarbeitung entscheiden

Ein Datenschutz-Informationsmanagementsystem (PIMS) nach ISO/IEC 27701:2025 funktioniert nur, wenn Datenschutzrollen vor Beginn der Verarbeitung festgelegt werden. Diese operative Disziplin verhindert, dass Article 26 nach einem Vorfall rekonstruiert werden muss.

Clarysecs Richtlinie für das Datenschutz-Informationsmanagementsystem, Abschnitt 4.2.2, lautet:

[Gemeinsam Verantwortliche] Die für Lieferantenmanagement bzw. Beschaffung verantwortliche Person MUSS die Verantwortlichkeitszuweisung zwischen gemeinsam Verantwortlichen in REG08 dokumentieren, bevor die gemeinsame Verarbeitung beginnt.

Die Formulierung „bevor die gemeinsame Verarbeitung beginnt“ ist der Kontrollpunkt. Sie bedeutet: bevor die Plattformintegration produktiv gesetzt wird, bevor das gemeinsame Dashboard aktiviert wird, bevor die CRM-Synchronisierung startet, bevor Kampagnenzielgruppen aktiviert werden und bevor Betroffenenanfragen eingehen.

Die unterstützende Inventarpflicht steht in der Richtlinie zum PII-Verarbeitungsinventar und zur Rechtsgrundlage, Abschnitt 4.3.5:

[Gemeinsam Verantwortliche] Die für Lieferantenmanagement bzw. Beschaffung verantwortliche Person MUSS den Zweck der Verarbeitung durch gemeinsam Verantwortliche und die Referenz auf die Verantwortlichkeitszuweisung in REG02 und REG08 erfassen, bevor die Verarbeitung durch gemeinsam Verantwortliche beginnt.

Zusammen schaffen diese Abschnitte die Nachweiskette, die Auditoren erwarten:

• REG02 dokumentiert Verarbeitungstätigkeit, Zweck, Datenkategorien, Rechtsgrundlage, Aufbewahrung, Systeme, Empfänger, Übermittlungen und Referenz auf gemeinsam Verantwortliche.
• REG08 dokumentiert die Vereinbarung zwischen gemeinsam Verantwortlichen und die Verantwortlichkeitszuweisung.
• REG07 dokumentiert die öffentlich sichtbare Transparenzzusammenfassung.
• REG06 kann Eingang, Weiterleitung, Validierung, Fristen und Antwortnachweise für Betroffenenanfragen dokumentieren.
• REG10 dokumentiert Entscheidungen zur Bewertung von Vorfällen und Datenschutzverletzungen.

Diese Kette macht aus Article 26 keine bloße rechtliche Aussage, sondern einen Managementsystem-Prozess.

Mit Geltungsbereich, interessierten Parteien und RACI beginnen

Der Zenith Blueprint beginnt mit Geltungsbereich und interessierten Parteien, weil Governance für gemeinsam Verantwortliche scheitert, wenn interessierte Parteien und Anforderungen zu spät identifiziert werden.

In der Phase ISMS Foundation & Leadership, Step 2, Anforderungen interessierter Parteien und ISMS-Geltungsbereich, empfiehlt der Zenith Blueprint eine Analyse interessierter Parteien, die explizite und implizite Anforderungen erfasst:

So identifizieren Sie Anforderungen und Erwartungen: Listen Sie für jede identifizierte Gruppe interessierter Parteien auf, was sie
in Bezug auf Informationssicherheit benötigt. Einige Anforderungen sind explizit (Gesetze, Verträge,
SLAs), andere sind implizit (Erwartungen oder allgemein anerkannte gute Praxis). Hilfreich ist:

✓ Prüfen Sie die für Ihren Kontext geltenden gesetzlichen und regulatorischen Anforderungen (aus der
Kontextanalyse in Step 1). Erstellen Sie eine Liste spezifischer Klauseln oder Verpflichtungen mit Bezug zu
Informationssicherheit oder Datenschutz.
✓ Prüfen Sie Verträge und Vereinbarungen: Viele Geschäftsverträge enthalten Vertraulichkeits- oder
Sicherheitsanhänge. Extrahieren Sie diese Anforderungen.
✓ Führen Sie Interviews oder Workshops mit interessierten Parteien durch: Binden Sie Vertreter aus
jeder Gruppe ein (z. B. einen HR-Manager für die Beschäftigtenperspektive, einen Vertriebsleiter für
Kundenerwartungen), um ihre Anliegen oder Anforderungen zu verstehen.
✓ Berücksichtigen Sie Branchenstandards oder Verhaltenskodizes, deren Einhaltung interessierte Parteien von Ihnen
erwarten.

Für eine auditierbare Vereinbarung zwischen gemeinsam Verantwortlichen nach GDPR Article 26 sollte die Analyse der interessierten Parteien Kunden, Patienten, Nutzer, Aufsichtsbehörden, die anderen verantwortlichen Parteien, Auftragsverarbeiter, Unterauftragsverarbeiter, Versicherer, Cloud-Anbieter, interne Abteilungen, Regulierungsbehörden und Leitungsorgane umfassen.

Step 4, Rollen und Verantwortlichkeiten im ISMS, überführt diese Analyse anschließend in Zuständigkeiten. Der Zenith Blueprint hebt den Nutzen eines RACI-Modells hervor:

✓ Rechenschaftspflicht vs. Verantwortung: Ein nützliches Werkzeug ist hier eine RACI-Matrix (Responsible,
Accountable, Consulted, Informed). Für jeden wesentlichen ISMS-Prozess oder jede wesentliche Kontrolle wird festgelegt,
wer Responsible ist (die Arbeit ausführt), wer Accountable ist (letztlich rechenschaftspflichtig, häufig eine
Führungskraft), wer Consulted ist (Input liefert) und wer Informed ist.

Für gemeinsam Verantwortliche ist RACI in der Praxis nicht optional. Ohne RACI nimmt die Rechtsabteilung an, dass Datenschutz die Anfrage beantwortet, Datenschutz nimmt an, dass Support die Eingangswarteschlange betreut, Support nimmt an, dass der Partner antwortet, und die gesetzliche Frist läuft weiter.

Das Clarysec-Nachweismodell für gemeinsam Verantwortliche

Eine ausgereifte Vereinbarung zwischen gemeinsam Verantwortlichen sollte auf einer Seite verständlich und innerhalb von zehn Minuten nachweisbar sein. Ziel ist nicht, Teams in juristischem Schriftverkehr zu begraben. Ziel ist, Verantwortlichkeiten sichtbar, akzeptiert und testbar zu machen.

Die Datenschutzrichtlinien von Clarysec stärken jede Ebene.

Die Richtlinie zu Datenschutzhinweisen und Transparenz, Abschnitt 4.1.5, lautet:

[Gemeinsam Verantwortliche] Die datenschutzverantwortliche Person / der PIMS-Manager MUSS die öffentlich sichtbare Zusammenfassung der Verantwortlichkeiten gemeinsam Verantwortlicher und die Kontaktstelle in REG07 erfassen, bevor die Verarbeitung durch gemeinsam Verantwortliche gestartet oder wesentlich geändert wird.

Die Richtlinie zum Management der Rechte betroffener Personen, Abschnitt 6.1.5, lautet:

[Gemeinsam Verantwortliche] Die datenschutzverantwortliche Person / der PIMS-Manager MUSS Verantwortlichkeiten für die Bearbeitung von Rechten und Kontaktwege in REG02, REG06 oder REG08 dokumentieren, bevor die Verarbeitung durch gemeinsam Verantwortliche beginnt.

Die Richtlinie zum Management von PII-Vorfällen und Datenschutzverletzungen, Abschnitt 4.2.5, ergänzt:

[Gemeinsam Verantwortliche] Die datenschutzverantwortliche Person / der PIMS-Manager MUSS die vereinbarte Verantwortung für Datenschutzverletzungen, die führende Kommunikationsverantwortung und die Koordinationsregelung vor jeder externen Meldung oder Kommunikation durch einen gemeinsam Verantwortlichen überprüfen und die Entscheidung in REG08 und REG10 dokumentieren.

An diesem Punkt werden ISO/IEC 27701:2025 und GDPR operativ. Die Organisation sagt nicht nur, dass Verantwortlichkeiten zugewiesen sind. Sie zeigt, wo sie dokumentiert sind, wer sie genehmigt hat, wann sie getestet wurden und wie sie genutzt werden.

Praktisches Beispiel: REG08 für eine Remote-Monitoring-Plattform

Angenommen, CareConnect und MetroHealth betreiben gemeinsam eine Remote-Monitoring-Plattform. Beide entscheiden, warum Patientendaten verarbeitet werden, welche Daten erhoben werden, wie Monitoring-Warnmeldungen konfiguriert sind, wie Analysen genutzt werden und wie Patienten mit dem Service interagieren.

Zuerst sollte REG02 die Verarbeitungstätigkeit dokumentieren:

• Name der Verarbeitung: Remote-Patientenmonitoring-Service
• Rolle des Verantwortlichen: Gemeinsam Verantwortlicher
• Parteien: CareConnect und MetroHealth
• Zweck: Patientenmonitoring, Pflegekoordination, Serviceverbesserung, Plattformanalysen
• PII-Kategorien: Kontaktdaten, Kontokennungen, klinische Beobachtungen, Geräteereignisse, Supportinteraktionen
• Prüfung besonderer Kategorien: Gesundheitsdaten werden verarbeitet und erfordern erhöhte Schutzmaßnahmen
• Rechtsgrundlage: je Partei und Zweck dokumentiert
• Aufbewahrung: definiert anhand klinischer, plattformbezogener, rechtlicher und operativer Anforderungen
• Systeme: mobile Anwendung, Monitoring-Plattform, Support-Werkzeug, Analyse-Warehouse, Identitätsanbieter
• Empfänger: gemeinsam verantwortliche Parteien, Hosting-Anbieter, Support-Dienstleister, Benachrichtigungsanbieter
• Übermittlungen: Fernzugriff und Verarbeitung außerhalb des EWR bewertet
• REG08-Referenz: JC-2026-004

Anschließend sollte REG08 die Verantwortlichkeiten so zuweisen, dass operative Teams danach handeln können.

Drittens sollte REG07 die öffentlich sichtbare Zusammenfassung dokumentieren. Der Hinweis sollte den Kern der gemeinsamen Vereinbarung in klarer Sprache erklären, die gemeinsam Verantwortlichen benennen, beschreiben, wofür jede Partei verantwortlich ist, und eine nutzbare Kontaktstelle bereitstellen. Er sollte Patienten oder Nutzer nicht zwingen, interne operative Komplexität zu entschlüsseln.

Viertens ist der Workflow vor der Produktivsetzung zu testen. Senden Sie ein simuliertes Auskunftsersuchen an die veröffentlichte Kontaktstelle. Bestätigen Sie, dass Support es als Anfrage zur Ausübung von Betroffenenrechten erkennt, an Datenschutz weiterleitet, REG08 prüft, Partnerinput anfordert, Maßnahmen in REG06 dokumentiert und ein Antwortpaket erstellt. Führen Sie anschließend eine Tabletop-Übung zu einer Datenschutzverletzung mit einem Szenario durch, etwa „API-Endpunkt legt Patientenkennungen gegenüber nicht autorisierten Nutzern offen“ oder „Nutzer mit ausgesetzter Löschung werden versehentlich in eine Engagement-Kampagne aufgenommen“.

Diese Tests zeigen die tatsächlichen Lücken: nicht zugewiesene Postfächer, unklare Partner-SLAs, nicht genehmigter Hinweistext, unvollständige Aufzeichnungen zur Rechtsgrundlage, fehlende Prüfungen besonderer Kategorien und Vorfall-Playbooks, die keinen Verantwortlichen für externe Kommunikation benennen.

Article 26 über Zenith Controls auf ISO/IEC 27002:2022-Maßnahmen abbilden

Eine Vereinbarung zwischen gemeinsam Verantwortlichen ist nicht nur ein Rechtsdokument. Sie muss durch technische und organisatorische Kontrollen getragen werden. Zenith Controls unterstützt Teams dabei, Kontrollerwartungen aus ISO/IEC 27001:2022 und ISO/IEC 27002:2022 auf Datenschutz-, Lieferanten-, Vorfall-, Cloud- und Governance-Nachweise abzubilden.

Drei Maßnahmen aus ISO/IEC 27002:2022 sind besonders relevant.

Maßnahme 5.2, Rollen und Verantwortlichkeiten für Informationssicherheit, unterstützt das Betriebsmodell. Sie ist mit ISO/IEC 27001:2022 Abschnitt 5.3, organisatorische Rollen, Verantwortlichkeiten und Befugnisse, verbunden. Sie unterstützt auch die Vorfallsbereitschaft, weil unklare Rollen ISO/IEC 27002:2022 Control 5.24, Planung und Vorbereitung des Managements von Informationssicherheitsvorfällen, untergraben. In der Governance gemeinsam Verantwortlicher ist Control 5.2 die Stelle, an der RACI, REG08-Verantwortliche, DSR-Bearbeitende, Verantwortliche für Datenschutzverletzungen und Eskalationskontakte zu Auditnachweisen werden.

Maßnahme 5.31, Gesetzliche, regulatorische, satzungsmäßige und vertragliche Anforderungen, ist der Punkt, an dem GDPR Article 26 Teil des ISMS wird und kein reines Rechtsthema bleibt. Sie unterstützt Identifizierung und Management der Rechenschaftspflicht nach GDPR Article 5, der Rechtsgrundlage nach Article 6, der Verantwortlichkeitszuweisung nach Article 26, der Sicherheit nach Article 32, der Meldung an die Aufsichtsbehörde nach Article 33 und der Benachrichtigung betroffener Personen nach Article 34. Sie ist außerdem mit ISO/IEC 27001:2022 Abschnitt 4.2, Verstehen der Erfordernisse und Erwartungen interessierter Parteien, und Abschnitt 6.1.3, Informationssicherheitsrisikobehandlung, verbunden.

Maßnahme 5.34, Datenschutz und Schutz personenbezogener Daten, bringt den Schutz von PII in das Sicherheitsbetriebsmodell. Dies ist besonders wichtig, wenn die Vereinbarung Cloud-Analysen, gemeinsame Dashboards, Datenreinräume, Monitoring-Plattformen, Marketingautomatisierung oder Support-Werkzeuge nutzt. Zugehörige Schutzmaßnahmen können ISO/IEC 27002:2022 Control 5.23, Informationssicherheit bei Nutzung von Cloud-Services, und Control 8.11, Datenmaskierung, umfassen.

Auch das unterstützende ISO-Ökosystem ist relevant. ISO/IEC 27018 hilft, wenn öffentliche Cloud-Services PII verarbeiten. ISO/IEC 29100 stellt Datenschutzgrundsätze wie Transparenz, Einwilligung, legitimen Zweck, Erhebungsbegrenzung, Datenminimierung, Nutzungsbegrenzung, Richtigkeit, Sicherheitsmaßnahmen und Rechenschaftspflicht bereit. ISO/IEC 27001:2022 liefert das Rückgrat des Managementsystems über Kontext, interessierte Parteien, Geltungsbereich, Führung, Risikobeurteilung, Risikobehandlung, Anwendbarkeitserklärung, internes Audit, Managementbewertung und kontinuierliche Verbesserung.

Verträge müssen zum Betriebsmodell passen

Eine Vereinbarung zwischen gemeinsam Verantwortlichen darf nicht nur im Datenschutzhinweis existieren. Sie muss sich in Verträgen, Anhängen, Betriebsverfahren, Vorfall-Playbooks, Eskalationswegen und Beendigungsklauseln widerspiegeln.

Clarysecs Richtlinie zur rechtlichen und regulatorischen Einhaltung, Abschnitt 5.3.1.2, bezieht Vertragsarten ausdrücklich in die Governance ein, einschließlich:

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

Die Richtlinie zu Datenschutz und Privatsphäre, Abschnitt 5.1, legt die Unternehmensgrundlage fest:

Die Organisation muss ein formales Datenschutz-Governance-Rahmenwerk unterhalten, das in das Informationssicherheits-Managementsystem (ISMS) integriert ist, um diese Richtlinie durchzusetzen.

Für KMU wird derselbe Grundsatz auf die operative Realität skaliert. Die Richtlinie zu Datenschutz und Privatsphäre für KMU, Abschnitt 5.2.1, lautet:

Der Datenschutzkoordinator muss ein Register aller Verarbeitungstätigkeiten personenbezogener Daten führen, einschließlich Datenkategorien, Zweck, Rechtsgrundlage und Aufbewahrungsfristen

Abschnitt 5.2.2 ergänzt:

Verträge mit Dritten, die personenbezogene Daten verarbeiten, müssen Datenschutzklauseln enthalten und durch den Geschäftsführer (GM) oder Rechtsberater geprüft werden

Das ist verhältnismäßige Governance. Ein multinationales Unternehmen kann getrennte Teams für Recht, Datenschutz, Beschaffung, Sicherheit, Risiko und Compliance haben. Ein KMU kann sich auf einen Datenschutzkoordinator, einen Geschäftsführer und einen externen Rechtsberater stützen. Die Nachweiserwartung bleibt dieselbe: Verarbeitungstätigkeiten, Verantwortlichkeiten, Rechtsgrundlage, Hinweise, Bearbeitung von Rechten, Vorfalleskalation und Beendigungspflichten müssen dokumentiert und prüfbar sein.

Der Zenith Blueprint, Step 23, Organisatorische Maßnahmen, unterstützt die Disziplin bei Lieferantenvereinbarungen durch Vertraulichkeit, Verantwortlichkeiten für Zugriffskontrolle, technische und organisatorische Maßnahmen, Fristen zur Vorfallmeldung, Auditrechte, Kontrollen für Unterauftragnehmer und Regelungen zum Vertragsende. In Beziehungen gemeinsam Verantwortlicher sollten diese Klauseln auf Datenweitergabe und Verantwortlichkeitszuweisung angepasst werden, statt aus einer Vorlage für Auftragsverarbeiter kopiert zu werden.

Governance für Vorfälle und Datenschutzverletzungen: die führende Rolle vor der Datenschutzverletzung festlegen

Datenschutzverletzungen bei gemeinsam Verantwortlichen werden chaotisch, wenn Teams bis zum Vorfall warten, um zu entscheiden, wer extern kommuniziert.

GDPR definiert eine Verletzung des Schutzes personenbezogener Daten als eine Verletzung der Sicherheit, die zur versehentlichen oder unrechtmäßigen Vernichtung, zum Verlust, zur Veränderung, zur unbefugten Offenlegung von oder zum unbefugten Zugang zu personenbezogenen Daten führt. Soweit erforderlich, muss die Meldung an die Aufsichtsbehörde unverzüglich und, soweit möglich, innerhalb von 72 Stunden nach Bekanntwerden der Verletzung erfolgen. NIS2 und DORA können zusätzliche Erwartungen an Cybervorfallmeldungen und Kundenkommunikation hinzufügen.

Clarysecs Incident-Response-Richtlinie für KMU, Abschnitt 5.3.2, erfasst die zeitliche Disziplin:

Reaktionsfristen, einschließlich Datenwiederherstellung und Meldepflichten, müssen dokumentiert und an rechtlichen Anforderungen ausgerichtet werden, beispielsweise an der GDPR-Anforderung zur Meldung von Verletzungen personenbezogener Daten innerhalb von 72 Stunden.

Der Zenith Blueprint, Step 5, Kommunikation, Sensibilisierung und Kompetenz, betont die Planung externer Kommunikation, einschließlich Kunden, Aufsichtsbehörden, Partner und Öffentlichkeit. Für gemeinsam Verantwortliche sollte die Vorfallmatrix festlegen, wer die initiale Klassifizierung der Datenschutzverletzung durchführt, wer den anderen Verantwortlichen kontaktiert, wer feststellt, ob PII betroffen ist, wer Meldeschwellen bewertet, wer Behördenmeldungen entwirft, wer mit Personen kommuniziert, wer NIS2- oder DORA-Meldungen koordiniert, wer öffentliche Stellungnahmen genehmigt und wer Nachweise in REG10 dokumentiert.

Wenn die Vereinbarung ein Finanzunternehmen unter DORA umfasst, sollte der Vorfallprozess außerdem die Klassifizierung schwerwiegender IKT-bezogener Vorfälle, Eskalation an die obere Führungsebene, Zwischenaktualisierungen, Abschlussberichte und Kundenkommunikation unterstützen, wenn finanzielle Interessen betroffen sind. Wenn die Organisation in den Geltungsbereich von NIS2 fällt, kann die Meldung erheblicher Vorfälle gestufte Benachrichtigung und Kommunikation mit Dienstleistungsempfängern erfordern.

Die sicherste Praxis ist eine gemeinsame Tabletop-Übung vor der Produktivsetzung. Ein gutes Szenario zwingt Teams, REG08, REG10, das Vorfall-Playbook, Partnerkontakte, Meldevorlagen, Eskalationsbäume und Nachweisprotokolle unter Zeitdruck zu nutzen.

Cross-Compliance: Article 26 steht selten allein

Vereinbarungen zwischen gemeinsam Verantwortlichen sind häufig Teil breiter regulierter Ökosysteme. Eine FinTech-Kampagne, eine vernetzte Gesundheitsplattform, eine Managed-Service-Beziehung, eine Cloud-Marktplatzintegration oder eine Partnerschaft im Bereich digitaler Infrastruktur kann Pflichten über GDPR hinaus auslösen.

NIS2 kann für mittlere und große wesentliche oder wichtige Einrichtungen in Sektoren wie digitaler Infrastruktur, Cloud Computing, Rechenzentren, Managed Service Providern, Managed Security Service Providern, Online-Marktplätzen, Suchmaschinen und Plattformen sozialer Netzwerke gelten. NIS2 Article 20 legt die Aufsicht über das Cybersicherheitsrisikomanagement auf Leitungsorgane. Article 21 verlangt technische, operative und organisatorische Maßnahmen, einschließlich Risikoanalyse, Umgang mit Informationssicherheitsvorfällen, Aufrechterhaltung des Geschäftsbetriebs, Sicherheit der Lieferkette, sichere Entwicklung, Schwachstellenbehandlung, Schulung, Verschlüsselung, HR-Sicherheit, Zugriffskontrolle, Asset-Management und Authentifizierung. Article 23 führt eine gestufte Meldung erheblicher Vorfälle ein.

DORA gilt ab dem 17. Januar 2025 für viele Finanzunternehmen. DORA umfasst IKT-Risikomanagement, Meldung schwerwiegender IKT-bezogener Vorfälle, Testen der digitalen operationalen Resilienz, IKT-Drittparteienrisiko, vertragliche Vereinbarungen mit IKT-Anbietern und Aufsicht über kritische IKT-Drittdienstleister. DORA Article 5 verankert IKT-Risiko-Governance auf Ebene des Leitungsorgans. Articles 8 bis 14 decken Asset-Identifizierung, Schutz, Erkennung, Kontinuität, Backup, Wiederherstellung, Erkenntnisse aus Vorfällen, Schulung und Krisenkommunikation ab. Articles 17 bis 20 definieren Vorfallslebenszyklus und Meldung. Articles 28 bis 30 machen IKT-Drittparteienrisiko, Vertragsbedingungen, Register, Konzentrationsrisiko, Auditrechte und Exit-Planung zu zentralen Verpflichtungen.

NIST CSF 2.0 bietet eine praktische Integrationsschicht. Die GOVERN Function umfasst rechtliche, regulatorische, vertragliche, datenschutzbezogene und bürgerrechtliche Verpflichtungen, Rechenschaftspflicht der Führungsebene, Risikobereitschaft, Richtlinien, Aufsicht und Lieferantenrisiko. Ergebnisse wie GV.OC-03 und GV.SC-02 passen natürlich zu Nachweisen nach Article 26, weil sie verlangen, dass rechtliche Pflichten und Partnerrollen verstanden, gesteuert, kommuniziert und koordiniert werden.

Der Vorteil des Clarysec-Modells liegt in der Wiederverwendung von Nachweisen. REG08 ist nicht nur eine GDPR-Aufzeichnung. Es unterstützt Rechenschaftspflicht nach ISO/IEC 27701:2025, Governance nach ISO/IEC 27001:2022, Klarheit über Lieferantenrollen nach NIST CSF 2.0, DORA-Drittparteien-Governance bei Beteiligung von Finanzdienstleistungen und NIS2-Aufsicht durch das Management, soweit die Einrichtung in den Geltungsbereich fällt.

Was Auditoren und Aufsichtsbehörden prüfen werden

Unterschiedliche Prüfer betrachten Governance für gemeinsam Verantwortliche aus unterschiedlichen Perspektiven, laufen aber auf dieselbe Kernfrage hinaus: Kann die Organisation nachweisen, dass Rechenschaftspflicht funktioniert?

Die stärkste Auditposition ist Nachvollziehbarkeit. Beginnen Sie mit der rechtlichen Anforderung, verknüpfen Sie sie mit der PIMS-Richtlinie, verweisen Sie auf den Registereintrag, zeigen Sie den Workflow und anschließend Testnachweise oder eine echte Fallaufzeichnung.

Beispiel: GDPR Article 26 verlangt die Zuweisung der Verantwortlichkeiten gemeinsam Verantwortlicher. Die Richtlinie für das Datenschutz-Informationsmanagementsystem verlangt REG08 vor Beginn der Verarbeitung. REG08 zeigt die Verantwortlichkeitszuweisung für Hinweise, Rechte, Datenschutzverletzungen, Aufbewahrung, Lieferantenmanagement und Kontakte. REG07 zeigt die öffentlich sichtbare Zusammenfassung. Eine DSR-Simulation belegt, dass der Workflow funktioniert. Protokolle der Managementbewertung zeigen Ausnahmen, Entscheidungen und Verbesserungen.

Das ist auditierbare Governance.

Managementbewertung macht Datenschutzrisiko zur Rechenschaftspflicht der Geschäftsleitung

Governance für gemeinsam Verantwortliche darf nicht in einem Datenschutzordner verborgen bleiben. Sie gehört in die Managementbewertung, weil sie regulatorische Exponierung, Kundenvertrauen, Patientenvertrauen, Vorfallsbereitschaft, Lieferantenrisiko, vertragliche Haftung und operationale Resilienz beeinflusst.

ISO/IEC 27001:2022 verlangt Führungsverpflichtung, Rollen, Ressourcen, Richtlinienausrichtung, risikobasierte Planung, Leistungsbewertung und kontinuierliche Verbesserung. NIS2 legt Aufsichtspflichten für Cybersicherheit auf Leitungsorgane. DORA legt die letztendliche Verantwortung für IKT-Risiken bei Finanzunternehmen auf das Leitungsorgan.

Clarysecs Governance-Rollen- und Verantwortlichkeitenrichtlinie für KMU, Abschnitt 5.5, lautet:

Alle wesentlichen Sicherheitsentscheidungen, Ausnahmen und Eskalationen müssen dokumentiert und nachvollziehbar sein.

Für Unternehmen verlangt die Governance-Rollen- und Verantwortlichkeitenrichtlinie, Abschnitt 5.2:

Ein Rollen- und Verantwortlichkeitenregister muss geführt werden und muss Folgendes enthalten:

Dieses Register sollte Datenschutz-Governance-Rollen enthalten, soweit sie Sicherheit, Incident Response, Lieferantensicherung, operationale Resilienz und Berichterstattung an die Geschäftsleitung betreffen. Ausnahmen bei gemeinsam Verantwortlichen sollten vor der Produktivsetzung eskaliert werden, nicht erst nach einer Beschwerde entdeckt werden.

Ein praktikables Nachweispaket für die Managementbewertung sollte enthalten:

• Neue und geänderte Vereinbarungen zwischen gemeinsam Verantwortlichen
• Abschlussstatus von REG08
• Verarbeitungstätigkeiten mit hohem Risiko und DPIA-Status, soweit anwendbar
• Offene Themen zu Rechtsgrundlage oder Transparenz
• DSR-Leistung und überfällige Partnermaßnahmen
• Ergebnisse von Tabletop-Übungen zu Datenschutzverletzungen und ungelöste Lücken
• Abhängigkeiten von Lieferanten, Unterauftragsverarbeitern, Cloud und Übermittlungen
• Ausnahmen bei Aufbewahrung und Beendigung
• Audit-Feststellungen und Status der Abhilfemaßnahmen
• Auswirkungen auf die Berichterstattung zu GDPR, NIS2, DORA, NIST CSF 2.0 und COBIT 2019

Ein Clarysec-Ansatz in fünf Schritten, um Article 26 auditierbar zu machen

Wenn Ihre Organisation gemeinsam mit einer anderen Partei über die Verarbeitung von PII entscheidet, warten Sie nicht auf eine Beschwerde, ein Audit, eine Datenschutzverletzung oder einen Partnerstreit, um Verantwortlichkeiten zu klären.

Nutzen Sie diesen Fünf-Schritte-Ansatz:

1. Nutzen Sie Zenith Blueprint Step 2, um interessierte Parteien, rechtliche Anforderungen, Partnererwartungen, Datenschutzpflichten und regulatorischen Geltungsbereich zu identifizieren.
2. Nutzen Sie Zenith Blueprint Step 4, um ein RACI für Hinweise, Rechtsgrundlage, Rechte, Kommunikation bei Datenschutzverletzungen, Aufbewahrung, Übermittlungen, Lieferanten, Auditnachweise und Beendigung aufzubauen.
3. Erfassen Sie die Verarbeitungstätigkeit in REG02 und die Verantwortlichkeitszuweisung zwischen gemeinsam Verantwortlichen in REG08 mit dem PIMS-Richtliniensatz von Clarysec.
4. Bilden Sie die Vereinbarung über Zenith Controls ab, insbesondere auf ISO/IEC 27002:2022 Control 5.2, Control 5.31 und Control 5.34.
5. Testen Sie die Vereinbarung mit einer DSR-Simulation und einer Tabletop-Übung zu Datenschutzverletzungen, bevor die Verarbeitung beginnt.

CareConnect und MetroHealth brauchten keine zusätzliche informelle Abstimmung. Sie brauchten eine dokumentierte Verantwortlichkeitszuweisung, eine öffentlich sichtbare Zusammenfassung, einen Workflow für Rechte, eine Aufzeichnung zur Koordination bei Datenschutzverletzungen, Vertragsklauseln und Nachweise zur Managementbewertung.

Das ist der Unterschied zwischen „wir dachten, der Partner kümmert sich darum“ und „hier sind die genehmigte Vereinbarung, der Hinweis, der Workflow, die Testnachweise und die Entscheidungsaufzeichnung zur Datenschutzverletzung“.

Clarysec kann Sie dabei unterstützen, PIMS-Governance nach ISO/IEC 27701:2025 umzusetzen, sie an GDPR Article 26 auszurichten, in Ihr ISMS nach ISO/IEC 27001:2022 zu integrieren und auditbereite Nachweise über GDPR, NIS2, DORA, NIST CSF 2.0 und COBIT 2019 hinweg zu erzeugen.

Bereit, Unklarheiten bei gemeinsam Verantwortlichen durch auditbereite Nachweise zu ersetzen? Entdecken Sie den Zenith Blueprint: 30-Schritte-Roadmap für Auditoren, nutzen Sie Zenith Controls: Der Cross-Compliance-Leitfaden, oder kontaktieren Sie Clarysec für eine PIMS- und ISMS-Bewertung, die Article 26 in ein operatives Kontrollsystem überführt, bevor Ihre nächste Partnerschaft produktiv gesetzt wird.