DSB-Übergabedatei für GDPR und ISO 27701

Die Benachrichtigung traf in Marias Posteingang mit der harmlosen Betreffzeile „Team Update“ ein. David, der Datenschutzbeauftragte (DSB) ihres schnell wachsenden Fintech-Unternehmens, hatte eine neue Position angenommen. In zwei Wochen würde er gehen.

Zunächst behandelte Maria, die CISO, den Vorgang wie jeden anderen Weggang einer Führungskraft. HR würde das Offboarding durchführen, IT würde Zugriffe deaktivieren, die Rechtsabteilung würde offene Angelegenheiten prüfen, und der neue DSB würde ein Übergabegespräch erhalten. Dann begannen die eigentlichen Fragen.

„Wo ist die DSFA für die biometrische Login-Funktion?“

„Kann ich die Korrespondenz mit der belgischen Datenschutzaufsichtsbehörde zur Anfrage über den grenzüberschreitenden Datenfluss aus dem Vorjahr sehen?“

„Wie wurde die Akzeptanz des Datenschutz-Restrisikos beim KI-gestützten Kredit-Scoring-Modell begründet?“

Am folgenden Montag um 08:17 Uhr verlangte das Leitungsorgan die Zusicherung, dass die GDPR-Rechenschaftspflicht weiterhin intakt war. Ein großer Unternehmenskunde hatte einen Datenschutz-Due-Diligence-Fragebogen geschickt und verlangte das aktuelle VVT, das DSFA-Register, das Protokoll zu Datenschutzverletzungen, die Liste der Unterauftragsverarbeiter, den Datenaufbewahrungsplan und Nachweise zur Datenschutzberatung. Das Produktteam wollte eine Analytics-Änderung freigegeben bekommen. Der Support hielt drei Betroffenenanfragen. Die Beschaffung verhandelte einen Auftragsverarbeitungsvertrag neu. Das Sicherheitsteam untersuchte ein Ereignis, das personenbezogene Daten betreffen konnte.

Davids Übergabe bestand aus einem 30-minütigen Telefonat und einem gemeinsamen Laufwerk mit uneinheitlichen Ordnernamen. Der Kontext, die Abwägungen, die Entscheidungen zur Risikobereitschaft, die Historie mit Aufsichtsbehörden und die informelle Beratung waren mit ihm zur Tür hinausgegangen.

Genau dort zeigt sich, ob Datenschutz-Governance ein Managementsystem ist oder nur das Gedächtnis einer einzelnen Person.

Eine DSB-Übergabedatei für GDPR und ISO/IEC 27701:2025 ist kein HR-Austrittspaket. Sie ist eine Kontinuitätsdatei für die Rechenschaftspflicht. Sie zeigt dem neuen DSB, der Datenschutzleitung, dem PIMS-Manager, dem Auditor, der Aufsichtsbehörde oder dem Sponsor aus der Geschäftsleitung, was verarbeitet wird, warum es rechtmäßig ist, welche Risiken offen sind, wo die Nachweise liegen, wer die nächste Maßnahme verantwortet und welche Fristen nicht versäumt werden dürfen.

Das verborgene Datenschutzrisiko: Rechenschaftspflicht in einer einzigen Rolle

GDPR macht Rechenschaftspflicht ausdrücklich. Article 5(2) verlangt von Verantwortlichen, für die Einhaltung der Grundsätze der Rechtmäßigkeit, Verarbeitung nach Treu und Glauben und Transparenz, Zweckbindung, Datenminimierung, Richtigkeit, Speicherbegrenzung, Integrität und Vertraulichkeit verantwortlich zu sein und diese Einhaltung nachweisen zu können. Articles 4, 6, 9, 10 und 30 ergänzen den operativen Wortschatz und die Nachweiserwartungen, die einen Rollenwechsel überstehen müssen: personenbezogene Daten, Verarbeitung, Rechtsgrundlage, Bedingungen für besondere Kategorien personenbezogener Daten, Definitionen von Datenschutzverletzungen und Verzeichnis von Verarbeitungstätigkeiten.

Die Frage ist nicht, ob eine Organisation einen fähigen DSB hatte. Die Frage ist, ob das Datenschutzprogramm funktionsfähig bleibt, wenn der DSB wechselt.

Wenn ein DSB ausscheidet, muss die Organisation weiterhin wissen:

• Welche Verarbeitungstätigkeiten aktiv, pausiert, außer Betrieb genommen oder in Prüfung sind.
• Welche Rechtsgrundlagen und Bedingungen für besondere Kategorien personenbezogener Daten die jeweilige Tätigkeit stützen.
• Welche DSFAs ungelöste Risiken oder bedingte Freigaben enthalten.
• Welche Betroffenenanfragen offen, verlängert, abgelehnt oder angefochten sind.
• Welche Datenschutzverletzungen gemeldet, nicht gemeldet oder noch in Bewertung sind.
• Welche Auftragsverarbeiter, Unterauftragsverarbeiter und Übermittlungsinstrumente bestehen.
• Welche Kommunikation mit Aufsichtsbehörden, Kundenzusagen und Auditmaßnahmen noch offen sind.
• Welche Datenschutzberatung erteilt wurde, wann sie erfolgte und auf welchen Annahmen sie beruhte.

Das ist die klassische Schlüsselpersonenabhängigkeit. Das Wissen des DSB wird zum primären Repository für Datenschutzentscheidungen, Risikobeurteilungen und Interaktionen mit Aufsichtsbehörden. Wenn diese Person geht, verliert die Organisation mehr als einen Rolleninhaber. Sie verliert die Nachvollziehbarkeit, die für den Nachweis der Einhaltung erforderlich ist.

Clarysecs Enterprise-Richtlinie zu Datenschutzrollen, Verantwortlichkeiten und Rechenschaftspflicht [C1] macht Rollenübergaben zu einer Nachweispflicht:

[Alle] Die Datenschutzleitung / der PIMS-Manager MUSS Nachweise zur Rollenübergabe innerhalb von 10 Geschäftstagen nach einem Rollenwechsel in REG01 und REG12 erfassen.

Aus dem Abschnitt „Implementation“, Richtlinienklausel 7.1.6.

Dieselbe Richtlinie verlangt auch Kommunikationsnachweise nach Neuzuweisung oder Ausscheiden:

[Alle] Die Datenschutzleitung / der PIMS-Manager MUSS Kommunikationsnachweise zu Rollenänderungen innerhalb von 10 Geschäftstagen nach Neuzuweisung oder Ausscheiden in REG11 aktualisieren.

Aus dem Abschnitt „Accountability evidence and communication“, Richtlinienklausel 4.5.4.

Diese beiden Klauseln machen aus einer Personalveränderung eine auditierbare Datenschutzkontrolle. Die Übergabe ist keine informelle Wissensweitergabe mehr. Sie wird zu dokumentierten PIMS-Nachweisen.

Was eine DSB-Übergabedatei tatsächlich ist

Eine gute DSB-Übergabedatei ist kein einzelnes PDF. Sie ist ein kontrolliertes Nachweispaket mit Index, Verantwortlichen, Links, Statusfeldern, Entscheidungshistorie und Abrufregeln. Sie sollte es einem neuen DSB ermöglichen, das Datenschutzprofil der Organisation innerhalb von Stunden und nicht erst nach Wochen zu verstehen.

Man kann sie als Flugschreiber des Datenschutzprogramms verstehen. Sie muss nicht nur zeigen, was geschehen ist, sondern auch, warum Entscheidungen getroffen wurden und was als Nächstes erfolgen muss.

Eine praxistaugliche DSB-Übergabedatei sollte vier Fragen beantworten:

1. Welche Datenschutzverpflichtungen und Entscheidungen sind derzeit aktiv?
2. Welche Nachweise belegen, dass diese Verpflichtungen gesteuert werden?
3. Wer verantwortet jedes offene Element während und nach der Übergabe?
4. Welche Risiken, Fristen oder regulatorischen Sensibilitäten erfordern sofortige Aufmerksamkeit?

Die Datei sollte nicht jeden Datensatz duplizieren. Duplizierung erzeugt veraltete Nachweise. Stattdessen sollte sie auf den maßgeblichen Datensatz verweisen, den Status erläutern, die Verantwortlichkeit benennen und die nächste erforderliche Entscheidung kennzeichnen.

Clarysecs Enterprise-PIMS-Richtlinie zu dokumentierter Information und Nachweismanagement [C2] schafft die Nachweisgrundlage:

[Alle] Die Datenschutzleitung / der PIMS-Manager MUSS vor der erstmaligen PIMS-Veröffentlichung und anschließend quartalsweise einen PIMS-Index für dokumentierte Information in REG12 pflegen.

Aus dem Abschnitt „PIMS documented information control“, Richtlinienklausel 4.1.1.

Sie verlangt außerdem Nachweise zum Abruf:

[Alle] Die Datenschutzleitung / der PIMS-Manager MUSS Anfragen zum Abruf von Auditnachweisen und den Erfüllungsstatus innerhalb von fünf Geschäftstagen nach Eingang der Anfrage in REG12 erfassen.

Aus dem Abschnitt „Access, protection, retrieval, and disclosure“, Richtlinienklausel 4.4.4.

Eine DSB-Übergabedatei sollte daher um REG12 oder einen gleichwertigen Index für dokumentierte Information aufgebaut werden. Wenn Datenschutznachweise während einer Übergabe nicht schnell auffindbar sind, können sie die Rechenschaftspflicht nicht stützen, wenn Auditoren, Kunden oder Aufsichtsbehörden Nachweise verlangen.

Die Kernstruktur einer auditbereiten DSB-Übergabedatei

Clarysec-Implementierungen unterteilen die DSB-Übergabedatei typischerweise in zehn Abschnitte. Diese Abschnitte geben dem neuen DSB eine einheitliche operative Sicht, ohne die maßgeblichen führenden Systeme zu ersetzen.

Der wertvollste Teil der Datei sind häufig nicht die Dokumente selbst. Es ist der Kontext zwischen den Dokumenten. Eine DSFA kann ein Ergebnis zeigen, aber der neue DSB muss auch wissen, welche Beratung erteilt wurde, welche Restrisiken akzeptiert wurden, welche Bedingungen angefügt wurden und ob diese Bedingungen weiterhin überwacht werden.

Das GDPR-Rückgrat: VVT, DSFAs, Betroffenenanfragen, Datenschutzverletzungen und Rechtsgrundlage

Eine DSB-Übergabedatei sollte mit dem operativen GDPR-Rückgrat beginnen. Genau hier scheitern viele Übergaben, weil der ausscheidende DSB die Historie hinter den Aufzeichnungen kennt, während der neue DSB nur Fragmente sieht.

Die Enterprise-Richtlinie zu Datenschutz und Privatsphäre [C3] weist dem DSB die Verantwortung für zentrale Aufzeichnungen zu:

Pflegt das Verzeichnis von Verarbeitungstätigkeiten (VVT) gemäß GDPR Article 30.

Aus dem Abschnitt „Roles and Responsibilities“, Richtlinienklausel 4.2.2.

Sie legt außerdem fest:

Leitet die regulatorische Kommunikation, führt Datenschutz-Folgenabschätzungen (DSFAs) durch und steuert Prozesse zur Meldung von Datenschutzverletzungen.

Aus dem Abschnitt „Roles and Responsibilities“, Richtlinienklausel 4.2.3.

Und zum Management von Betroffenenrechten:

Der Datenschutzbeauftragte (DSB) MUSS dokumentierte Prozesse für Entgegennahme, Validierung, Nachverfolgung und Beantwortung von Betroffenenanfragen pflegen.

Aus dem Abschnitt „Policy Implementation Requirements“, Richtlinienklausel 6.4.1.

Das sind keine getrennten administrativen Aufgaben. Sie bilden eine Kette der Rechenschaftspflicht.

Wenn eine betroffene Person die Löschung verlangt, benötigt der neue DSB das VVT zur Identifikation von Systemen und Auftragsverarbeitern, das Register der Rechtsgrundlagen zur Bewertung, ob die Löschung greift, den Datenaufbewahrungsplan zur Prüfung der Speicherbegrenzung, Lieferantenunterlagen zur Koordination nachgelagerter Löschung und das Register zu Betroffenenanfragen zum Nachweis von Zeitachse und Antwort. Wechselt der DSB während einer laufenden Anfrage, muss die Übergabedatei diese Kette bewahren.

Für kleinere Organisationen verwendet Clarysecs Richtlinie zu Datenschutz und Privatsphäre für SMEs [C4] skalierte Formulierungen, bewahrt aber denselben Grundsatz der Rechenschaftspflicht:

Pflegt Aufzeichnungen zu Verarbeitungstätigkeiten.

Aus dem Abschnitt „Roles and Responsibilities“, Richtlinienklausel 4.2.1.

Sie verlangt außerdem:

Der Datenschutzkoordinator MUSS ein Register aller Verarbeitungstätigkeiten für personenbezogene Daten einschließlich Datenkategorien, Zweck, Rechtsgrundlage und Aufbewahrungsfristen pflegen.

Aus dem Abschnitt „Governance Requirements“, Richtlinienklausel 5.2.1.

Und für Anfragen zu Betroffenenrechten:

Alle Antworten auf Betroffenenanfragen MÜSSEN in einem sicheren Register protokolliert werden; der Zugriff ist auf den Datenschutzkoordinator und den Geschäftsführer zu beschränken.

Aus dem Abschnitt „Policy Implementation Requirements“, Richtlinienklausel 6.5.4.

Sowohl für Enterprise- als auch für SME-Umgebungen sollte die Übergabedatei ein operatives Datenschutz-Dashboard enthalten, das den Status von VVT, DSFAs, Betroffenenanfragen, Datenschutzverletzungen, Aufbewahrungsprüfungen und Lieferantenüberprüfungen zeigt. So weist eine Organisation nach, dass GDPR-Rechenschaftspflicht nicht von einer einzelnen Person abhängt.

ISO/IEC 27701:2025: Rollenwechsel als kontrollierte PIMS-Nachweise

ISO/IEC 27701:2025 erweitert Datenschutz-Governance zu einem strukturierten Datenschutz-Informationsmanagementsystem (PIMS). Das bedeutet, dass Rollenwechsel wie jeder andere kontrollierte Prozess behandelt werden sollten: geplant, zugewiesen, nachgewiesen, überprüft und verbessert.

Die Übergabedatei sollte für jeden wesentlichen Datenschutzprozess PIMS-Kontinuitätsfelder enthalten:

• Prozessname, z. B. DSFA, VVT, Betroffenenanfragen, Bewertung von Datenschutzverletzungen oder Datenschutzprüfung von Lieferanten.
• PIMS-Rolle, z. B. DSB, Datenschutzleitung, PIMS-Manager, Vertreter des Verantwortlichen oder Vertreter des Auftragsverarbeiters.
• Operative Rolle, z. B. Verantwortlicher, Auftragsverarbeiter, gemeinsam Verantwortlicher oder Unterauftragsverarbeiter.
• Aktueller Verantwortlicher und temporärer Stellvertreter.
• Referenz im Nachweisregister.
• Datum der letzten Prüfung und Datum der nächsten Prüfung.
• Offene Entscheidungen und ungelöste Risiken.
• Eskalationsweg.
• Links zu Richtlinienklauseln, Verfahren und Vorlagen.
• Auditstatus, einschließlich letzter Nachweisanfrage und Antwort.

Die Enterprise-Richtlinie zum Datenschutz-Informationsmanagementsystem [C5] macht die Datenschutzberatung selbst zu einem Nachweisobjekt:

[Alle] Der Datenschutzbeauftragte (DSB) / Datenschutzberater MUSS Datenschutzberatung zum PIMS-Geltungsbereich, zu DSFA-Kriterien und zu Entscheidungen mit hohem Risiko vor Freigabe der relevanten Entscheidung in REG04 erfassen.

Aus dem Abschnitt „Roles and Responsibilities“, Richtlinienklausel 5.1.3.

Diese Klausel ist während der Übergabe entscheidend. Der DSFA-Bericht kann die finale Freigabe zeigen, aber REG04 oder ein gleichwertiges Register zur Datenschutzberatung bewahrt die fachliche Begründung hinter der Entscheidung. Ohne diese Aufzeichnung kann der neue DSB möglicherweise nicht erklären, warum die Organisation eine Verarbeitungstätigkeit mit hohem Risiko freigegeben hat oder welche Überwachungsbedingungen daran geknüpft waren.

Clarysec verbindet Rollenwechsel außerdem mit der breiteren Governance. Die Enterprise-Richtlinie zu Governance-Rollen und Verantwortlichkeiten [C6] legt fest:

Delegationen sind im Rollen- und Verantwortlichkeitenregister nachzuverfolgen; der ursprüngliche Verantwortliche behält die letztendliche Rechenschaftspflicht.

Aus dem Abschnitt „Policy Implementation Requirements“, Richtlinienklausel 6.2.5.

Dies verhindert die gefährlichste Übergabelücke: Alle nehmen an, dass jemand anderes Betroffenenanfragen, DSFAs, Bewertungen von Datenschutzverletzungen oder Antworten an Aufsichtsbehörden abdeckt. Eine belastbare DSB-Übergabedatei enthält eine Delegationstabelle und stellt klar, ob jede Verantwortung dauerhaft, interimistisch oder beratend ist.

Aufbau des Repository mit dem Zenith Blueprint

Eine Übergabedatei ist nur so nützlich wie das Repository dahinter. Ein chaotisches gemeinsames Laufwerk ist kein PIMS-Nachweissystem.

Clarysecs Zenith Blueprint: 30-Schritte-Roadmap für Auditoren [C7] behandelt Dokumentation als lebendes Managementsystem. In der Phase ISMS Foundation & Leadership, Schritt 6, „Documented Information and Building the ISMS Library“, empfiehlt der Zenith Blueprint Organisationen, ein strukturiertes ISMS-Dokumentationsrepository aufzubauen:

Jetzt ist ein guter Zeitpunkt, eine Struktur für die Speicherung Ihrer gesamten ISMS-Dokumentation einzurichten (Ihre „ISMS-Bibliothek“). Zum Beispiel:

✓ Ein Hauptordner mit dem Namen „ISMS Documentation“ mit Unterordnern wie: ✓ Policies and Procedures: enthält die genehmigten Versionen von Richtlinien (z. B. InfoSec Policy, Acceptable Use Policy) und Verfahren (Incident-Response-Verfahren, Backup-Verfahren usw.). ✓ Risk Assessment & SoA: ein Ordner für Risikobeurteilungsberichte, Risikoregister (Arbeitsdatei) und die Anwendbarkeitserklärung (SoA), sobald sie entworfen ist. ✓ Training & Awareness Records: Schulungsprotokolle, Kopien bereitgestellter Inhalte, Teilnahmelisten. ✓ Audit and Review: interne Auditberichte, Protokolle der Managementbewertung, Protokolle zu Korrekturmaßnahmen. ✓ Incident Records: Vorfallsprotokoll, Vorfallsberichte, Lessons-Learned-Dokumente. ✓ Assets & Inventory: Listen von Assets, Ergebnisse der Datenklassifizierung usw. ✓ Annex A Controls (oder „Controls Library“): gegebenenfalls die Liste der Kontrollen und Dokumentation dazu, wie sie umgesetzt sind.

Stellen Sie sicher, dass dieses Repository zugänglich, aber sicher ist. Richtlinien können beispielsweise in einem Ordner mit Lesezugriff für alle Beschäftigten liegen, während der Ordner zur Risikobeurteilung auf das ISMS-Team und die oberste Leitung beschränkt sein kann.

Aus der Phase ISMS Foundation & Leadership, Schritt 6: Documented Information and Building the ISMS Library.

Für eine DSB-Übergabedatei wird dasselbe Muster zu einer PIMS-Bibliothek. Ein praktikabler Hauptordner lautet „PIMS DPO Handover and Accountability“ mit beschränktem Zugriff für DSB, Datenschutzleitung, Rechtsabteilung, CISO, Interne Revision und freigegebene Führungskräfte.

Für SMEs kann derselbe Grundsatz einfacher umgesetzt werden. Clarysecs Richtlinie zur Audit- und Compliance-Überwachung für SMEs [C8] legt fest:

Alle Nachweise MÜSSEN in einem zentralen Auditordner gespeichert werden.

Aus dem Abschnitt „Policy Implementation Requirements“, Richtlinienklausel 6.2.1.

Der Reifegrad kann variieren, der Grundsatz jedoch nicht. Datenschutznachweise müssen zentralisiert, kontrolliert, indexiert und abrufbar sein.

Die ISO-Kontrollanker: Rollen, Aufzeichnungen und Schutz personenbezogener Daten

Die DSB-Übergabedatei lässt sich deutlich drei organisatorischen Maßnahmen aus ISO/IEC 27002:2022 zuordnen, die in Clarysecs Zenith Controls: The Cross-Compliance Guide [C9] dargestellt sind. Dabei handelt es sich um ISO-Kontrollen, nicht um ein von Zenith erstelltes separates Kontrollset.

Diese Kontrollen stehen auch mit den Anforderungen des Managementsystems nach ISO/IEC 27001:2022 in Verbindung. Clause 5.3 verlangt, dass organisatorische Rollen, Verantwortlichkeiten und Befugnisse zugewiesen und kommuniziert werden. Clause 7.5 verlangt die Lenkung dokumentierter Information. Clause 6.1 verlangt Planung zu Risiken und Chancen einschließlich Risikobehandlung. Clause 8.1 verlangt operative Planung und Steuerung. Clause 9.1 verlangt Überwachung und Bewertung. Clause 10.2 verlangt Korrekturmaßnahmen.

Eine DSB-Übergabedatei unterstützt jede dieser Erwartungen, indem sie Rollenwechsel in kontrollierte, auditierbare Nachweise überführt.

Eine Übung in einer Sitzung zum Aufbau der DSB-Übergabedatei

Sie müssen nicht auf eine Kündigung warten. Führen Sie diese Übung vor dem Ausscheiden eines DSB, während eines internen Datenschutzaudits oder nach der Benennung einer neuen Datenschutzleitung durch.

Schritt 1: Übergabeindex erstellen

Öffnen Sie REG12 oder Ihren Index für dokumentierte Information und erstellen Sie einen Abschnitt mit dem Namen „DPO Handover File“. Ergänzen Sie Felder für:

• Nachweiselement.
• Prozessbereich.
• Maßgeblicher Speicherort.
• Verantwortlicher.
• Stellvertretender Verantwortlicher.
• Zuletzt geprüft.
• Nächste Prüfung.
• Vertraulichkeitsstufe.
• Offene Maßnahme.
• Auditrelevanz.

Befüllen Sie die ersten 25 Einträge. Beginnen Sie mit VVT, DSFA-Register, Register zu Betroffenenanfragen, Protokoll zu Datenschutzverletzungen, Lieferantenregister, Datenaufbewahrungsplan, Register zur Datenschutzberatung, Datei zur Behördenkorrespondenz, Datenschutz-Risikoregister und PIMS-Geltungsbereich.

Schritt 2: Fristenübersicht für 30, 60 und 90 Tage aufbauen

Erstellen Sie ein Red-Zone-Dashboard für Elemente, die in den nächsten 30, 60 und 90 Tagen fällig sind. Nehmen Sie auf:

• Offene Betroffenenanfragen.
• Ausstehende DSFA-Freigaben.
• Offene Bewertungen von Datenschutzverletzungen.
• Fristen für Antworten an Aufsichtsbehörden oder Kunden.
• Termine für Lieferantenüberprüfungen.
• Fristen für Mitteilungen zu Übermittlungen oder Unterauftragsverarbeitern.
• Meilensteine für Aufbewahrungsprüfungen.
• Korrekturmaßnahmen aus Audits.

Dies ist die Seite, die der neue DSB zuerst liest.

Schritt 3: Prozesse mit hohem Risiko namentlichen Verantwortlichen zuordnen

Verwenden Sie das Rollen- und Verantwortlichkeitenregister. Dokumentieren Sie für jeden Prozess, ob der ausscheidende DSB rechenschaftspflichtig, verantwortlich, konsultiert oder informiert war. Weisen Sie für jeden laufenden Prozess einen interimistischen Verantwortlichen zu. Verfolgen Sie die Delegation und kommunizieren Sie die Änderung im Einklang mit der Richtlinie zu Datenschutzrollen, Verantwortlichkeiten und Rechenschaftspflicht und der Richtlinie zu Governance-Rollen und Verantwortlichkeiten.

Schritt 4: Entscheidungskontext bewahren

Fügen Sie für jede aktive DSFA oder Entscheidung mit hohem Risiko eine knappe Notiz zur Entscheidungshistorie hinzu:

• Was wurde vorgeschlagen?
• Warum war eine DSFA erforderlich oder nicht erforderlich?
• Welche Datenschutzberatung wurde erteilt?
• Welche Risiken bestehen fort?
• Wer hat das Restrisiko akzeptiert?
• Welche Bedingungen müssen überwacht werden?

Hier wird REG04 unverzichtbar. Ohne aufgezeichnete Beratung sieht der neue DSB möglicherweise nur die finale Freigabe und übersieht die dahinterliegenden Einschränkungen.

Schritt 5: Abruf testen

Bitten Sie die Interne Revision oder die Compliance-Funktion, fünf Elemente aus der Übergabedatei anzufordern:

1. Den VVT-Eintrag für eine Verarbeitungstätigkeit mit hohem Risiko.
2. Die DSFA und den Beratungsdatensatz für dieselbe Tätigkeit.
3. Den unterstützenden Auftragsverarbeitungsvertrag.
4. Die Aufbewahrungsregel, die für die Daten gilt.
5. Die jüngste Entscheidung zu einer Betroffenenanfrage oder Datenschutzverletzung zu diesem Prozess, sofern vorhanden.

Wenn das Team diese Elemente nicht innerhalb der in der Richtlinie festgelegten Frist abrufen kann, ist die Übergabedatei nicht bereit.

Lieferanten-, Auftragsverarbeiter- und Cloud-Abhängigkeiten

Viele DSB-Übergaben scheitern an der Schnittstelle zwischen Datenschutz, Beschaffung, Sicherheit und Betrieb.

Ein ausscheidender DSB weiß möglicherweise, dass ein Auftragsverarbeiter eine ungelöste Audit-Feststellung hat, dass eine Mitteilung zu Unterauftragsverarbeitern geprüft werden muss oder dass einem Vertrag ausreichende Klauseln zur Unterstützung bei Vorfällen fehlen. Wird dieses Wissen nicht erfasst, übernimmt der neue DSB ein verborgenes Risiko.

Clarysecs Richtlinie zur Lieferanten- und Drittparteiensicherheit für SMEs [C10] legt die Nachweisgrundlage fest:

Ein Lieferantenregister MUSS vom administrativen oder Beschaffungskontakt gepflegt und aktualisiert werden. Es MUSS Folgendes enthalten:

Aus dem Abschnitt „Governance Requirements“, Richtlinienklausel 5.4.

Die Übergabedatei sollte das Lieferantenregister verknüpfen mit:

• Auftragsverarbeitungsverträgen.
• Listen der Unterauftragsverarbeiter.
• Dokumentation zu Übermittlungen.
• Sicherheits-Due-Diligence.
• Klauseln zur Meldung von Vorfällen.
• Auditrechten.
• Exit- und Löschverpflichtungen.
• Offenen Abhilfemaßnahmen.

Hier werden auch NIS2 und DORA relevant.

NIS2 verlangt von wesentlichen und wichtigen Einrichtungen die Umsetzung angemessener technischer, operativer und organisatorischer Maßnahmen zum Management von Cybersicherheitsrisiken. Die Risikomanagementbereiche umfassen den Umgang mit Informationssicherheitsvorfällen, die Aufrechterhaltung des Geschäftsbetriebs, die Sicherheit der Lieferkette, sichere Beschaffung und Entwicklung, Schwachstellenbehandlung, Wirksamkeitsbewertung, Cyberhygiene, Schulung, Kryptografie, Personalsicherheit, Zugriffskontrolle und Asset-Management.

DORA verlangt von Finanzunternehmen IKT-Governance, IKT-Risikomanagement, Klassifizierung und Meldung von Vorfällen, Tests der digitalen operationalen Resilienz und IKT-Drittparteienrisikomanagement. Für kritische oder wichtige Funktionen erwartet DORA außerdem belastbare vertragliche Schutzmaßnahmen, Zugriffs- und Auditrechte, Kündigungsrechte, Exit-Strategien und Übergangsregelungen.

Eine DSB-Übergabedatei sollte ausweisen, wo datenschutzrelevante Lieferanten zugleich Teil von Verpflichtungen zur operationalen Resilienz sind. Wenn ein Auftragsverarbeiter einen kritischen Finanzservice oder einen wichtigen digitalen Dienst unterstützt, muss der neue DSB die regulatorischen Auswirkungen eines Lieferantenausfalls, einer verzögerten Vorfallmeldung oder einer Vertragsschwäche verstehen.

Kontinuität bei Vorfällen und Datenschutzverletzungen

Der Kontext von Datenschutzverletzungen ist sehr vergänglich. Während einer DSB-Übergabe geht leicht verloren, warum entschieden wurde, nicht zu melden, warum eine Meldung verzögert wurde oder warum eine bestimmte Personengruppe als betroffen galt.

GDPR definiert eine Verletzung des Schutzes personenbezogener Daten weit, einschließlich unbeabsichtigter oder unrechtmäßiger Vernichtung, Verlust, Veränderung, unbefugter Offenlegung von oder unbefugtem Zugang zu personenbezogenen Daten. Incident Response muss daher eine Datenschutz-Triage einschließen, nicht nur technische Eindämmung.

Der Zenith Blueprint betont in der Phase Controls in Action, Schritt 23, die rechtliche Schnittstelle bei datenschutzbezogenen Kontrollen:

Die Kontrolle führt außerdem eine rechtliche Schnittstelle in das ISMS ein. Datenschutzverantwortliche, Rechtsberater oder Datenschutzbeauftragte (DSB) müssen daran beteiligt sein, festzulegen, wie personenbezogene Daten verarbeitet werden, insbesondere bei internationalen Übermittlungen, grenzüberschreitender Verarbeitung oder Betroffenenrechten wie Auskunft, Berichtigung und Löschung. Das sind nicht nur Rechte, sondern operative Verpflichtungen, und sie müssen durch strukturierte, auditierbare Prozesse unterstützt werden.

Aus Auditsicht steht diese Kontrolle zunehmend im Fokus. Auditoren, Aufsichtsbehörden und Kunden wollen gleichermaßen sehen:

✓ Wo personenbezogene Daten liegen, ✓ welche Rechtsgrundlage ihre Verarbeitung regelt, ✓ wie der Zugriff beschränkt wird, ✓ wie Vorfälle gemeldet werden, ✓ und wie die Organisation Rechte wahrt und Transparenz aufrechterhält.

Aus der Phase Controls in Action, Schritt 23: Organisatorische Maßnahmen (5.19–5.37).

Für jeden offenen oder kürzlich geschlossenen Vorfall mit personenbezogenen Daten sollte die Übergabedatei ein Kontinuitätsblatt für Datenschutzverletzungen enthalten.

Dies unterstützt auch die Vorfallerwartungen aus NIS2 und DORA. NIS2 nutzt abgestufte Meldungen für erhebliche Vorfälle, einschließlich Frühwarnung, Meldung, erforderlicher Aktualisierungen und Abschlussbericht. DORA verlangt von Finanzunternehmen, schwerwiegende IKT-bezogene Vorfälle zu erkennen, zu steuern, zu klassifizieren und zu melden, mit Erst-, Zwischen- und Abschlussmeldungen sowie Ursachenanalyse. Ein neuer DSB muss zwischen Sicherheitsvorfall, Verletzung des Schutzes personenbezogener Daten, erheblichem NIS2-Vorfall und schwerwiegendem DORA-IKT-bezogenem Vorfall unterscheiden können, auch wenn ein Ereignis mehrere Workflows auslöst.

Aufbewahrung und Entsorgung: das stille Übergaberisiko

Aufbewahrungsregeln veralten bei Rollenwechseln häufig, weil sie zwischen Rechtsabteilung, Records Management, IT und Geschäftsverantwortlichen liegen. Die GDPR-Speicherbegrenzung verlangt jedoch, dass personenbezogene Daten nicht länger aufbewahrt werden, als es für die Verarbeitungszwecke erforderlich ist.

Die Enterprise-Richtlinie zur Datenaufbewahrung und Entsorgung [C11] weist eine Datenschutzkontrollrolle zu:

Prüft und validiert Datenaufbewahrungspläne für personenbezogene Daten, um eine Rechtsgrundlage für die fortgesetzte Speicherung sicherzustellen.

Aus dem Abschnitt „Roles and Responsibilities“, Richtlinienklausel 4.3.2.

Die Übergabedatei sollte Datenaufbewahrungspläne mit Prüfbedarf, Systeme mit technischen Löschbeschränkungen, Legal Holds, archivierte Datenbestände, Probleme bei der Backup-Aufbewahrung und Abhängigkeiten von Löschungen bei Auftragsverarbeitern identifizieren.

Ein nützlicher Test ist einfach. Wählen Sie einen VVT-Eintrag aus und fragen Sie, ob der neue DSB Aufbewahrungsfrist, Löschtrigger, Systemverantwortlichen, Beteiligung von Auftragsverarbeitern, Behandlung in Backups und Nachweise der letzten Prüfung bestimmen kann. Falls nicht, ist die Rechenschaftspflicht für Aufbewahrung nicht übergabebereit.

Cross-Compliance-Zuordnung: eine Datei, viele Erwartungen

Eine belastbare DSB-Übergabedatei ersetzt keine gesetzlichen Verpflichtungen, gibt Auditoren und Aufsichtsbehörden aber einen kohärenten Nachweispfad über mehrere Rahmenwerke hinweg.

NIST CSF 2.0 ist besonders nützlich als Kommunikationsebene. Seine GOVERN-Funktion erwartet, dass gesetzliche, regulatorische, vertragliche, datenschutzbezogene und bürgerrechtliche Verpflichtungen verstanden und gesteuert werden. Die Methode der Organizational Profiles hilft Organisationen, Ist- und Zielzustände zu definieren, Richtlinien und Risikoinformationen zusammenzuführen, Lücken zu identifizieren und priorisierte Maßnahmenpläne zu erstellen.

Genau das leistet eine DSB-Übergabedatei. Sie definiert das aktuelle Datenschutzprofil, identifiziert Zielanforderungen für Kontinuität und erstellt eine priorisierte Liste von Abhilfemaßnahmen.

Wie Auditoren einen DSB-Übergabeprozess prüfen

Ein ernsthafter Auditor wird nicht dabei stehen bleiben, nach dem Namen des DSB zu fragen. Er wird testen, ob die Datenschutzfunktion resilient ist.

Die häufigste Feststellung lautet nicht, dass keine Übergabedatei existiert. Sie lautet, dass die Datei Nachweise nicht mit Entscheidungen verknüpft. Auditoren wollen nicht nur Dokumente. Sie wollen Nachvollziehbarkeit.

Häufige Fehlermuster und Clarysec-Lösungen

Das erste Fehlermuster ist die Übergabe per Posteingang. Der ausscheidende DSB leitet E-Mails weiter, aber es gibt kein indexiertes Nachweisregister. Clarysec behebt dies, indem Nachweise in REG12 geführt und jedes Element mit Prozess, Verantwortlichem und Prüfdatum verknüpft werden.

Das zweite ist die Vorlagenübergabe. Die Organisation hat DSFA- und Vorlagen für Betroffenenanfragen, aber keinen aktuellen Status. Clarysec behebt dies mit einem Red-Zone-Dashboard zu offenen Fristen, Entscheidungen mit hohem Risiko und ungelösten Maßnahmen.

Das dritte ist Richtlinie ohne Delegation. Richtlinien sagen, dass der DSB den Datenschutz verantwortet, aber niemand erfasst interimistische Verantwortung. Clarysec behebt dies über das Rollen- und Verantwortlichkeitenregister, Nachweise zur Rollenübergabe in REG01 und REG12 sowie Kommunikationsnachweise in REG11.

Das vierte ist der Lieferantenblindspot. Datenschutzunterlagen von Auftragsverarbeitern sind nicht mit Beschaffungs- und Sicherheitsunterlagen verknüpft. Clarysec behebt dies durch Verbindung von Lieferantenregister, DPA-Repository, Unterauftragsverarbeiterliste, Vorfallklauseln, Exit-Pflichten und Sicherheits-Due-Diligence.

Das fünfte ist die Kontextlücke bei Vorfällen. Der technische Vorfalldatensatz existiert, aber die Begründung zur Datenschutzverletzung fehlt. Clarysec behebt dies durch Kontinuitätsblätter für Datenschutzverletzungen, die Meldeanalyse, Auswirkungen auf betroffene Personen, Entscheidungen gegenüber Aufsichtsbehörden und Lessons Learned bewahren.

Ihre 30-Tage-Checkliste zur DSB-Übergabebereitschaft

Wenn Ihr DSB oder Ihre Datenschutzleitung morgen wechseln würde: Könnten Sie Kontinuität nachweisen? Nutzen Sie diese Checkliste.

• Bestätigen Sie, dass DSB, Datenschutzleitung, PIMS-Manager und Stellvertretungen im Rollenregister erfasst sind.
• Erfassen Sie Nachweise zur Rollenübergabe innerhalb von 10 Geschäftstagen in REG01 und REG12.
• Aktualisieren Sie Kommunikationsnachweise zu Rollenänderungen innerhalb von 10 Geschäftstagen in REG11.
• Verifizieren Sie, dass der REG12-PIMS-Index für dokumentierte Information aktuell ist.
• Erstellen Sie eine Fristenübersicht für Datenschutz für 30, 60 und 90 Tage.
• Prüfen Sie offene Betroffenenanfragen und bestätigen Sie die Antwortverantwortlichen.
• Prüfen Sie alle aktiven DSFAs und Entscheidungen mit hohem Risiko.
• Bestätigen Sie, dass REG04 Datenschutzberatung zu PIMS-Geltungsbereich, DSFA-Kriterien und Entscheidungen mit hohem Risiko enthält.
• Gleichen Sie das VVT mit Systemen, Lieferanten und Datenaufbewahrungsplänen ab.
• Prüfen Sie offene und jüngste Bewertungen von Datenschutzverletzungen.
• Bestätigen Sie, dass Auftragsverarbeiter-, Unterauftragsverarbeiter- und Lieferantendatensätze vollständig sind.
• Validieren Sie Datenaufbewahrungspläne für personenbezogene Daten.
• Testen Sie den Abruf von fünf kritischen Nachweiselementen.
• Berichten Sie den Übergabestatus an das Management.
• Nehmen Sie Lessons Learned in den PIMS-Verbesserungsplan auf.

Datenschutzkontinuität auditbereit machen, bevor die Rolle wechselt

Der beste Zeitpunkt zum Aufbau einer DSB-Übergabedatei ist, bevor jemand kündigt, bevor eine Aufsichtsbehörde fragt und bevor ein Vorfall das Thema erzwingt.

Clarysec unterstützt Organisationen dabei, Datenschutz-Governance in operative Nachweise zu überführen, indem Richtlinienvorlagen, PIMS-Register, Übergabe-Workflows, auditbereite Repositories und Cross-Compliance-Zuordnungen kombiniert werden. Beginnen Sie mit dem Zenith Blueprint für die 30-Schritte-Implementierungsroadmap, nutzen Sie Zenith Controls, um ISO/IEC 27002:2022-Kontrollen mit breiteren Compliance-Erwartungen zu verknüpfen, und richten Sie Ihre internen Klauseln an Clarysecs Datenschutz- und Nachweismanagement-Richtlinien aus.

Wenn Ihr DSB morgen wechseln würde: Würde Ihre Organisation den Kontext hinter jeder DSFA, jeder Entscheidung zu Datenschutzverletzungen, jedem VVT-Eintrag und jeder Zusage gegenüber Aufsichtsbehörden behalten?

Wenn die Antwort unsicher ist, ist der nächste Schritt praktisch. Erstellen Sie den Übergabeindex, ordnen Sie die Nachweise zu, benennen Sie interimistische Verantwortliche und testen Sie den Abruf noch in dieser Woche. Clarysec kann Ihnen helfen, diese Datei vollständig, kontrolliert und auditbereit zu machen.