Löschzertifikate für personenbezogene Daten bei Beendigung von Auftragsverarbeiter-Beziehungen

Maria, CISO eines wachsenden europäischen Fintech-Unternehmens, blickte auf eine kurze E-Mail von DataLeap, dem Anbieter einer Marketing-Analytics-SaaS-Lösung, die ihr Unternehmen gerade gekündigt hatte.

“Wir bestätigen, dass alle mit Ihrem Konto verbundenen Daten aus unseren Produktivsystemen gelöscht wurden.”

Die Nachricht war höflich, schnell und nahezu wertlos.

Drei Jahre lang hatte DataLeap Kundenkennungen, Kampagneninteraktionsdaten, Lead-Scoring-Attribute, Einwilligungsmetadaten und Verhaltensanalysen für Tausende von EU-Kunden verarbeitet. FinSecure bereitete sich auf ein DORA-Audit vor, der Datenschutzbeauftragte prüfte Nachweise zur GDPR-Rechenschaftspflicht, und das Beschaffungsteam wollte den Lieferantendatensatz vor dem nächsten Abrechnungszyklus schließen. Die E-Mail beantwortete nur eine sehr eng gefasste Frage: Produktivdaten. Sie sagte nichts über Backups, Protokolle, Support-Tickets, Analytics-Arbeitsbereiche, Caches von Unterauftragsverarbeitern, Testkopien, API-Zugangsdaten oder archivierte Berichte aus.

Maria stellte die Frage, mit der sich jeder CISO, Datenschutzbeauftragte und Compliance-Verantwortliche früher oder später bei der Trennung von einem SaaS-Anbieter konfrontiert sieht:

Wo ist das Löschzertifikat?

Diese Frage macht aus einer gewöhnlichen Vertragsbeendigung ein Compliance-Ereignis. Nach GDPR müssen Verantwortliche nachweisen können, dass sie Grundsätze wie Speicherbegrenzung, Integrität, Vertraulichkeit und Rechenschaftspflicht einhalten. Nach DORA müssen Finanzunternehmen IKT-Drittparteienrisiken über den gesamten Lebenszyklus der Beziehung hinweg steuern, einschließlich Beendigung und Exit-Strategien, die Störungen, regulatorische Non-Compliance und Schäden für Kunden verhindern. Nach ISO/IEC 27701:2025 benötigen Organisationen rollenbasierte PIMS-Nachweise für Tätigkeiten als Verantwortlicher, Auftragsverarbeiter, Unterauftragsverarbeiter und Cloud-PII-Processor. Nach ISO/IEC 27001:2022 müssen Lieferantenabhängigkeiten, externe Services, operative Kontrollen und aufbewahrte Nachweise innerhalb des Informationssicherheits-Managementsystems gesteuert werden.

Die Lücke wird selten beim Onboarding entdeckt. Sie zeigt sich beim Exit. Der Vertrag sagt, dass Daten gelöscht werden, definiert aber keine Nachweise. Der Cloud-Anbieter kann eine CSV exportieren, aber den Umgang mit Backups nicht erklären. Die Beschaffung kann den Lieferanten kündigen, aber die Compliance-Funktion kann die endgültige Disposition nicht belegen. IT kann Konten deaktivieren, aber der Entzug von Zugriff ist keine Löschung. Die Rechtsabteilung kann eine Kündigungsmitteilung versenden, aber Auditoren verlangen eine Nachweiskette.

Clarysec behandelt die Beendigung von Auftragsverarbeiter-Beziehungen als auditierbare Kontrollkette, nicht als administrativen Nachgedanken.

Warum der Exit von Auftragsverarbeitern zu einem Compliance-Schwerpunkt geworden ist

Das Ende einer Beziehung zu einem SaaS-, Payroll-, HR-, Finanz-, CRM-, Cloud-Hosting-, Marketing-Analytics- oder Managed-ICT-Service ist einer der risikoreichsten Momente im Lebenszyklus personenbezogener Daten. Im Normalbetrieb weiß die Organisation zumindest, welches System produktiv ist, wem es gehört und welcher Vertrag gilt. Bei der Beendigung fragmentiert die Verantwortung schnell. Die Beschaffung schließt den Lieferantendatensatz. IT deaktiviert Benutzer. Die Rechtsabteilung archiviert den Vertrag. Der Fachbereich wechselt auf die Nachfolgeplattform. Der alte Lieferant bewahrt Daten weiterhin im Rahmen standardmäßiger Backup-, Archiv- oder Protokollierungszyklen auf.

Genau diese Fragmentierung prüfen Auditoren und Aufsichtsbehörden.

GDPR definiert Verarbeitung weit, einschließlich Speicherung, Löschung und Vernichtung. GDPR unterscheidet Verantwortliche, die Zwecke und Mittel festlegen, von Auftragsverarbeitern, die im Auftrag von Verantwortlichen handeln. Article 5 legt Grundsätze wie Zweckbindung, Datenminimierung, Speicherbegrenzung sowie Integrität und Vertraulichkeit fest. Article 5(2) ergänzt den Grundsatz der Rechenschaftspflicht, wonach der Verantwortliche die Einhaltung nachweisen können muss. Article 28(3)(g) verlangt, dass Auftragsverarbeitungsverträge vorsehen, dass der Auftragsverarbeiter nach Wahl des Verantwortlichen am Ende der Leistungserbringung alle personenbezogenen Daten löscht oder zurückgibt und vorhandene Kopien löscht, sofern keine gesetzlichen Aufbewahrungspflichten entgegenstehen.

Eine informelle Lieferanten-E-Mail erfüllt diesen Maßstab selten, wenn es um Gehaltsabrechnungsdaten, Finanzunterlagen, Gesundheitsdaten, Kundenkennungen, Authentifizierungsprotokolle oder regulierte Kundendatensätze geht.

DORA erhöht die Anforderungen für Finanzunternehmen. Seit dem 17. Januar 2025 gilt DORA als Regelwerk der EU für die digitale operationale Resilienz im Finanzsektor. DORA verpflichtet Finanzunternehmen, IKT-Drittparteienrisiken als integralen Bestandteil ihres gesamten Risikorahmens zu steuern und auch bei Auslagerungen vollständig für die Einhaltung verantwortlich zu bleiben. DORA erwartet, dass Organisationen Informationsregister zu IKT-Serviceverträgen führen, Services zur Unterstützung kritischer oder wichtiger Funktionen identifizieren, Due Diligence durchführen, Konzentrationsrisiken bewerten, vertragliche Rechte für Zugriff, Wiederherstellung und Rückgabe von Daten vorsehen sowie Beendigungs- und Exit-Strategien aufrechterhalten.

Für kritische oder wichtige Funktionen müssen DORA-Verträge weiter gehen. Sie benötigen Regelungen zu Auditrechten, Übergangszeiträumen, Service Levels, Notfalltests, Mitwirkungspflichten und Exit-Unterstützung. Ein Löschzertifikat ist nicht das gesamte DORA-Exitpaket, aber ein kritisches Nachweisartefakt darin.

NIS2 ist auch für viele Anbieter in der breiteren IKT-Lieferkette relevant, einschließlich Cloud-Computing-Anbietern, Rechenzentrumsbetreibern, Managed Service Providern (MSPs), Managed Security Service Providern und anderen Anbietern digitaler Infrastruktur. NIS2 Article 21 verlangt geeignete und verhältnismäßige technische, operative und organisatorische Maßnahmen, einschließlich Sicherheit der Lieferkette, Steuerung von Lieferantenbeziehungen, Zugriffskontrolle, Asset-Management, Behandlung von Informationssicherheitsvorfällen, Kontinuität und Cyberhygiene. Für Finanzunternehmen, die DORA unterliegen, wirkt DORA in der Regel als sektorspezifischer Rechtsakt der Union für vergleichbare Anforderungen an IKT-Risiken, Meldungen, Tests und Drittparteien. NIS2 prägt jedoch weiterhin das breitere Cybersicherheitsökosystem.

Die praktische Botschaft ist einfach: Wenn ein Lieferant personenbezogene Daten verarbeitet, regulierte Abläufe unterstützt oder Teil Ihrer IKT-Servicekette war, sind Exit-Nachweise eine Risikokontrolle.

Die Sicht von Clarysec: Der Exit von Auftragsverarbeitern ist eine Kontrollkette

Ein ausgereifter Exit-Workflow für Auftragsverarbeiter beantwortet drei Fragen:

1. Welche Daten, Systeme und Unterauftragsverarbeiter sind im Geltungsbereich?
2. Welche Rückgabe-, Übermittlungs-, Lösch- oder Entsorgungsmaßnahme ist rechtlich und vertraglich erforderlich?
3. Welche Nachweise belegen, dass die Maßnahme abgeschlossen wurde, bevor der Exit geschlossen wurde?

In Zenith Controls: The Cross-Compliance Guide wird dieses Szenario ISO/IEC 27002:2022 Maßnahme 5.20, “Addressing information security within supplier agreements”; Maßnahme 8.10, “Information deletion”; und Maßnahme 7.14, “Secure disposal or re-use of equipment” zugeordnet. Das sind keine getrennten Checklistenpunkte. Der Exit von Auftragsverarbeitern verbindet Lieferantenvereinbarungen, Datenlebenszyklusmanagement, Cloud-Offboarding, Entzug von Zugriffsberechtigungen, Asset-Verantwortung, Nachweisaufbewahrung und Auditbereitschaft.

Clarysecs Zenith Blueprint: An Auditor’s 30-Step Roadmap verortet dies in der Phase “Controls in Action”. In Schritt 23, organisatorische Kontrollen, wird erwartet, dass Lieferantenvereinbarungen Regelungen zum Vertragsende, Kontrollen für Unterauftragnehmer, Auditrechte und Vorfallprotokolle abdecken. Der Blueprint beschreibt typische Bereiche von Lieferantenvereinbarungen unter anderem wie folgt:

“Regelungen zum Vertragsende, wie Datenrückgabe oder Vernichtung, Asset-Wiederherstellung und Kontodeaktivierung.”

An genau dieser Stelle treffen GDPR-Rechenschaftspflicht, ISO/IEC 27701:2025 PIMS-Nachweise, DORA-Exit-Erwartungen, NIS2-Sicherheit der Lieferkette und operative Kontrollen nach ISO/IEC 27001:2022 zusammen.

Derselbe Zenith Blueprint erläutert in Schritt 19, technologische Kontrollen I, das Löschrisiko hinter dem Exit von Auftragsverarbeitern:

“Diese Kontrolle stellt sicher, dass Daten nicht länger als erforderlich aufbewahrt werden und, wenn sie nicht mehr benötigt werden, sicher und zuverlässig gelöscht werden müssen.”

Schritt 18, physische Kontrollen II, übersetzt die Nachweiserwartung in praktische Anforderungen:

“Bei Nutzung eines externen Anbieters sind Vernichtungszertifikate als Auditnachweis anzufordern und aufzubewahren.”

Bei Cloud-basierten Systemen liegt die physische Entsorgung in der Regel außerhalb der direkten Kontrolle des Kunden. Dadurch werden vertragliche Löschbestätigungen, Compliance-taugliche Löschbescheinigungen und archivierte ISMS-Dokumentation noch wichtiger.

Das Betriebsmodell von Clarysec ist klar: Vertragsklausel, Exit-Auslöser, Dateninventar, Löschmaßnahme, Bestätigung des Unterauftragsverarbeiters, Nachweisregister, abschließende Verifikation.

Warum „gelöscht“ nicht dasselbe ist wie „nachgewiesen“

Eine typische Audit-Feststellung lautet:

“Die Organisation erklärte, dass der Lieferant die Daten gelöscht habe, konnte jedoch keine Nachweise zur Löschung, zum Löschumfang, zum Löschdatum, zur verantwortlichen Partei, zu den einbezogenen Systemen, zum Umgang mit Backups oder zur Bestätigung von Unterauftragsverarbeitern vorlegen.”

Das passiert in großen Unternehmen, ist aber auch bei KMU üblich, die stark auf SaaS-Werkzeuge für Gehaltsabrechnung, Support-Ticketing, CRM, HR-Onboarding, Cloud-Speicher, Zusammenarbeit, Analytics und Softwareentwicklung angewiesen sind. Wenn ein Lieferant wechselt, verbleiben personenbezogene Daten häufig in inaktiven Konten, Support-Anhängen, temporären Migrationsdateien, Entwicklungsexporten, Staging-Datenbanken und Backup-Zyklen.

Der Clarysec-Richtliniensatz macht aus „gelöscht“ eine Nachweisanforderung.

Die Third party and supplier security policy [P26] verlangt in Klausel 6.5.1.2:

“Rückgabe oder zertifizierte Vernichtung sämtlicher organisationseigener Informationen”

Klausel 6.5.1.3 verlangt anschließend:

“Abschließende Verifikation der Compliance, z. B. Prüfung von Protokollen und Compliance-Bescheinigungen”

Diese Unterscheidung ist wichtig. Ein Löschzertifikat ist nicht die gesamte Kontrolle. Es ist ein Artefakt innerhalb eines abschließenden Compliance-Verifikationspakets. Auditoren werden prüfen wollen, ob das Zertifikat zum Lieferantenvertrag, Dateninventar, Exit-Ticket, zu Zugriffsprotokollen, zur Liste der Unterauftragsverarbeiter, zum Datenaufbewahrungsplan und zur Risikobeurteilung passt.

Für KMU bietet die Third-Party and Supplier Security Policy - SME [P26S] eine praktikable Basislinie. Klausel 5.3.6 unter Governance-Anforderungen verlangt:

“Beendigungsbedingungen, einschließlich sicherer Datenrückgabe oder Vernichtung”

Klausel 6.4.2.3 unter Anforderungen an die Richtlinienumsetzung verpflichtet Lieferanten dazu:

“schriftlich zu bestätigen, dass Daten sicher gelöscht wurden”

Die Data Retention and Disposal Policy [P14] ergänzt in Klausel 4.7.2 die Nachweisanforderung:

“Auf Anfrage sind dokumentierte Nachweise der Compliance bereitzustellen, z. B. Löschprotokolle oder Vernichtungszertifikate.”

Für KMU verlangt die Data Retention Policy and Secure Disposal Policy - SME in Klausel 6.2.3:

“Entsorgungsereignisse müssen mit Datum, Datensatzkategorie, Verfahren und verantwortlicher Person protokolliert werden.”

Das ist der Unterschied zwischen Vertrauen in Lieferanten und Auditnachweis.

ISO/IEC 27701:2025: Rollenbasierte Exit-Nachweise

ISO/IEC 27701:2025 ergänzt das ISMS um eine Datenschutzmanagement-Ebene. Der Exit von Auftragsverarbeitern muss die PIMS-Rolle der Organisation widerspiegeln. Ein Verantwortlicher, der eine Beziehung zu einem Auftragsverarbeiter beendet, hat andere Verantwortlichkeiten als ein Auftragsverarbeiter, der eine Beziehung zu einem Unterauftragsverarbeiter beendet. Ein Auftragsverarbeiter, der auf Kundenweisung handelt, muss dokumentieren, dass er diese Weisung befolgt hat. Ein Cloud-Auftragsverarbeiter muss nachweisen, dass Rückgabe, Übermittlung, Löschung oder Entsorgung innerhalb des mit dem Kunden vereinbarten Zeitrahmens erfolgt ist.

Der PIMS-Richtliniensatz von Clarysec verwendet Rollenkennzeichnungen, um dies operativ umzusetzen. “Both” gilt unabhängig davon, ob die Organisation Verantwortlicher oder Auftragsverarbeiter ist. “Processor” gilt, wenn personenbezogene Daten auf dokumentierte Weisung des Verantwortlichen verarbeitet werden. “Subprocessor” gilt, wenn die Organisation durch einen anderen Auftragsverarbeiter beauftragt wurde.

Die Processor, Subprocessor and Third-Party Privacy Management Policy verlangt in Klausel 4.5.6:

“[Beide Rollen] Der Lieferanten- bzw. Beschaffungsverantwortliche MUSS Rückgabe-, Löschungs-, Entsorgungs- oder Übergangsnachweise in REG08 innerhalb von 30 Tagen nach Vertragsbeendigung, Ablauf, Kundenweisung oder genehmigtem Exit-Ereignis einholen, sofern keine kürzere vertragliche Frist gilt.”

Die PII Retention, Deletion and Disposal Policy trennt Pflichten von Auftragsverarbeitern und Unterauftragsverarbeitern. Klausel 4.3.3 lautet:

“[Auftragsverarbeiter] Der Lieferanten- bzw. Beschaffungsverantwortliche MUSS die kundengesteuerte Rückgabe, Übermittlung, Löschung oder Entsorgung bis zur vertraglichen Frist oder zum dokumentierten Datum der Kundenweisung in REG08 durchführen oder bestätigen.”

Klausel 4.3.4 lautet:

“[Unterauftragsverarbeiter] Der Lieferanten- bzw. Beschaffungsverantwortliche MUSS Nachweise zur Rückgabe, Löschung oder Entsorgung durch Unterauftragsverarbeiter innerhalb des vertraglichen Nachweiszeitraums nach Kundenweisung, Service-Exit oder Beendigung des Unterauftragsverarbeiters in REG08 einholen.”

Klausel 7.1.7 führt die Anforderung zurück zum Abschluss:

“[Beide Rollen] Der Lieferanten- bzw. Beschaffungsverantwortliche MUSS Nachweise von Auftragsverarbeitern, Unterauftragsverarbeitern oder externen Services für erforderliche Rückgabe-, Übermittlungs- oder endgültige Dispositionsmaßnahmen in REG08 einholen, bevor der Service-Exit geschlossen wird.”

Für Cloud-Services verlangt die Cloud PII Processor Policy in Klausel 4.6.3:

“[Auftragsverarbeiter] Der Systemverantwortliche bzw. Anwendungsverantwortliche MUSS genehmigte Rückgabe-, Übermittlungs-, Lösch- oder Entsorgungsmaßnahmen für kundenbezogene personenbezogene Daten innerhalb des mit dem Kunden vereinbarten Zeitrahmens abschließen und Abschlussnachweise in REG08 oder REG12 erfassen.”

Die operative Verbesserung ist unmittelbar. Warten Sie nicht auf ein Audit. Erstellen Sie die Nachweisanforderung bereits beim Exit-Auslöser, weisen Sie sie einem Verantwortlichen zu, setzen Sie eine Frist und verhindern Sie den Abschluss, bis REG08 oder REG12 vollständig ist.

Was ein gutes Nachweispaket für den Exit von Auftragsverarbeitern enthält

Ein Löschzertifikat sollte kein vages PDF mit Logo und einem Satz sein. Es sollte ein strukturiertes Nachweispaket unterstützen, das einer GDPR-Anfrage, einem ISO/IEC 27701:2025 PIMS-Audit, einem ISO/IEC 27001:2022 Überwachungsaudit, einer DORA-Anfrage einer Aufsichtsbehörde, einer Prüfung zur Vertrauensbildung bei Kunden oder einem internen Audit standhält.

Das ist keine Bürokratie. Es ist eine praktische Übergabekette für personenbezogene Daten beim Service-Exit.

Die Vertragsklausel, die die Krise verhindert

Marias Problem begann Jahre vor der letzten E-Mail von DataLeap. Es begann, als der Vertrag mit einer vagen Löschklausel und ohne Nachweispflicht unterzeichnet wurde. Der stärkste Exit-Workflow für Auftragsverarbeiter beginnt in der Beschaffung, nicht bei der Kündigung.

Für Cloud-Services verlangt die Enterprise-Cloud Usage Policy in Klausel 5.4.4:

“Beendigungsklauseln, die sicheres und verifizierbares Offboarding ermöglichen”

Für KMU verlangt die Cloud Usage Policy - SME in Klausel 6.3.5:

“Bestätigung sicherer Löschverfahren vor Kontoschließung”

Eine praktikable Lieferantenvertragsklausel sollte Rückgabe oder Löschung verlangen, Fristen definieren, Backups und Unterauftragsverarbeiter abdecken, Nachweise verlangen und Auditrechte sichern.

Musterklausel: Datenrückgabe, Löschung und Nachweise

Bei Beendigung oder Ablauf der Vereinbarung oder auf schriftliche Weisung des Verantwortlichen hat der Auftragsverarbeiter nach Wahl des Verantwortlichen alle personenbezogenen Daten in einem vereinbarten maschinenlesbaren Format sicher zurückzugeben oder alle personenbezogenen Daten aus Systemen, Medien, Backups und Umgebungen unter Kontrolle des Auftragsverarbeiters sicher zu löschen, sofern nicht Unionsrecht oder Recht eines Mitgliedstaats eine Speicherung verlangt.

Innerhalb von dreißig Kalendertagen nach Abschluss der erforderlichen Maßnahme oder innerhalb einer kürzeren vertraglich vereinbarten Frist stellt der Auftragsverarbeiter ein unterzeichnetes Löschzertifikat oder eine gleichwertige Compliance-Bescheinigung bereit. Das Zertifikat benennt den Service, die Datenkategorien, die abgedeckten Systeme, den Zeitraum der Löschung, das Löschverfahren, den Umgang mit Backups und Archiven, den Status der Unterauftragsverarbeiter, fortbestehende Ausnahmen und die autorisierte unterzeichnende Person.

Der Verantwortliche kann angemessene unterstützende Nachweise anfordern, einschließlich Protokollen, Entsorgungsaufzeichnungen, Bescheinigungen von Unterauftragsverarbeitern und Prozessdokumentation, um das Zertifikat zu verifizieren und den Exit-Datensatz des Lieferanten zu schließen.

Diese Formulierung macht Rechenschaftspflicht zu einem operativen Liefergegenstand.

Praxisbeispiel: Exit einer Payroll-SaaS-Lösung

Betrachten wir ein KMU, das von PayrollCloud A zu PayrollCloud B wechselt. PayrollCloud A verarbeitete Namen von Beschäftigten, Adressen, Steuerkennungen, Bankdaten, Gehaltshistorien, Krankheitsdaten und Support-Tickets. Als Unterauftragsverarbeiter nutzte es einen Cloud-Hosting-Anbieter und eine Support-Plattform.

Ein an Clarysec ausgerichteter Exit würde wie folgt ablaufen.

1. Exit-Ticket für den Lieferanten eröffnen

Die Beschaffung erstellt ein Exit-Ticket, das mit dem Lieferantendatensatz verknüpft ist. Das Ticket enthält das Vertragsbeendigungsdatum, das letzte Servicedatum, den Business Owner, den Systemverantwortlichen, den Datenschutzbeauftragten oder Datenschutzkontakt und die Angabe, ob besondere Kategorien personenbezogener Daten betroffen sein können. Da Payroll-Daten sensitive Beschäftigungs- und Gesundheitsdaten enthalten können, ist die Risikoeinstufung hoch.

2. Exit der Vereinbarung zuordnen

Der Lieferantenverantwortliche prüft den Vertrag auf Rückgabe-, Lösch-, Audit-, Übergangs- und Unterauftragsverarbeiterklauseln. Ist der Vertrag schwach, sendet der Verantwortliche dennoch eine formelle Weisung, die Rückgabe, Löschung und Bestätigung durch Unterauftragsverarbeiter verlangt. Die Nachweiserwartung ist in den Clarysec-Richtlinien verankert, einschließlich P26, P26S, P14, der Cloud Usage Policy und der Cloud Usage Policy - SME.

3. PII-Geltungsbereich definieren

Der Systemverantwortliche erstellt eine Erklärung zum Datenumfang, die Produktivdaten der Gehaltsabrechnung, Employee-Self-Service-Dokumente, Anhänge, Exporte, Support-Tickets, Audit-Protokolle mit Benutzerkennungen, API-Integrationsdateien, temporäre Migrationsextrakte, Backups, Snapshots und bei Unterauftragsverarbeitern gehaltene Daten abdeckt.

Dies unterstützt GDPR-Rechenschaftspflicht, ISO/IEC 27701:2025 PIMS-Nachweise, operative Kontrollen nach ISO/IEC 27001:2022 und, für Finanzunternehmen, die Erwartungen an das DORA-Informationsregister für IKT-Drittparteien.

4. Rückgabe-, Löschungs- und Unterauftragsverarbeiter-Nachweise anfordern

Der Lieferantenverantwortliche sendet eine strukturierte Anfrage an PayrollCloud A, um die abschließende Durchführung des Exports, die Löschung der Produktivmandantendaten, den Umgang mit Backups und unveränderlichen Archiven, die Löschung von Support-Ticket-Anhängen, den Entzug kundenspezifischer Konten und API-Zugangsdaten, Lösch- oder Entsorgungsnachweise von Unterauftragsverarbeitern sowie ein unterzeichnetes Löschzertifikat bestätigen zu lassen.

5. Abschluss in REG08 oder REG12 erfassen

Der Lieferantenverantwortliche erfasst jedes Nachweiselement in REG08. Wenn die Organisation als Auftragsverarbeiter handelt und die Cloud-Anwendung kundenbezogene personenbezogene Daten enthielt, kann der Abschluss zusätzlich nach der Cloud PII Processor Policy in REG12 erfasst werden.

6. Abschließende Verifikation vor der Schließung durchführen

Die Compliance-Funktion vergleicht das Löschzertifikat mit der Erklärung zum Datenumfang. IT prüft Zugriffsprotokolle und Nachweise zur Kontoschließung. Der Datenschutzbeauftragte prüft, ob Aufbewahrungsausnahmen bestehen, etwa eine gesetzliche Verpflichtung oder eine streitbezogene Sperre. Die Sicherheitsfunktion verifiziert, dass API-Token, Servicekonten und SSO-Konfigurationen entfernt wurden.

Erst danach wird das Exit-Ticket geschlossen.

Weigert sich der Lieferant, Nachweise bereitzustellen, wird das Thema zu einer Frage der Risikobehandlung. Es kann eine Eskalation, vertragliche Abhilfemaßnahmen, eine Analyse von Kundenmitteilungen, eine regulatorische Bewertung, verstärkte Überwachung während des Übergangs oder Änderungen der Lieferantenrisikoeinstufung auslösen.

DORA, NIS2 und IKT-Resilienz: Exit-Nachweise über Datenschutz hinaus

DORA behandelt den Lieferanten-Exit als Teil der Resilienz, nicht nur als Datenschutzadministration. Ein Finanzunternehmen bleibt auch dann für die Einhaltung verantwortlich, wenn IKT-Services ausgelagert werden. Es muss ein Informationsregister für IKT-Serviceverträge führen, Services zur Unterstützung kritischer oder wichtiger Funktionen unterscheiden, Due Diligence durchführen, Konzentrationsrisiken bewerten und Exit-Strategien aufrechterhalten.

Ein Löschzertifikat eines Auftragsverarbeiters kann mehrere DORA-Belange beeinflussen:

• Kontinuität von Kundenservices
• regulatorische Berichterstattung
• Datenintegrität
• Incident Response
• Auditrechte
• operationale Resilienz
• Wiederherstellungs- und Übergangsplanung
• Management kritischer oder wichtiger Funktionen

Für ein Zahlungsinstitut, Wertpapierunternehmen, Kreditinstitut, einen Anbieter von Krypto-Dienstleistungen oder eine Fintech-Plattform muss das Löschzertifikat Teil eines umfassenderen Exitpakets sein. Es reicht nicht aus, nachzuweisen, dass personenbezogene Daten gelöscht wurden, wenn die Organisation nicht auch belegen kann, dass die Serviceumstellung störungsfrei erfolgte, regulatorische Verpflichtungen weiterhin erfüllt wurden und Auswirkungen auf Kunden gesteuert wurden.

NIS2 erweitert die Diskussion zur Lieferantensicherheit über Finanzdienstleistungen hinaus. Der Exit von Auftragsverarbeitern ist ein Test der Sicherheit der Lieferkette. Wenn eine wesentliche oder wichtige Einrichtung nicht nachweisen kann, dass ein Lieferant Daten am Ende der Leistungserbringung zurückgegeben oder gelöscht hat, besteht eine Schwäche im Management von Lieferantenbeziehungen, in der Asset-Kontrolle, in der Zugriffsgovernance, im Datenschutz und potenziell in der Vorfallsbereitschaft.

Führt ein fehlgeschlagener Exit zu unbefugtem Zugriff, Verlust, Offenlegung oder Serviceunterbrechung, muss die Organisation möglicherweise Meldepflichten für Sicherheitsvorfälle nach anwendbarem Recht und nationalen Umsetzungsvorschriften bewerten.

Cross-Compliance-Mapping: Ein Workflow, viele Verpflichtungen

Der Wert eines gut konzipierten Exit-Workflows für Auftragsverarbeiter liegt darin, dass er mehrere Rahmenwerke gleichzeitig erfüllt.

NIST CSF 2.0 ist besonders nützlich als Kommunikationsschicht. Seine GOVERN-Funktion verlangt, dass Organisationen gesetzliche, regulatorische, vertragliche und Datenschutzverpflichtungen verstehen, eine Risikostrategie definieren, Rollen zuweisen und Aufsicht etablieren. Die Ergebnisse des Cybersecurity Supply Chain Risk Management decken Lieferantenanforderungen in Verträgen, Überwachung von Lieferantenrisiken und Aktivitäten nach dem Ende einer Partnerschaft oder Servicevereinbarung ab. GV.SC-10 ist genau der Ort, an den der Exit von Auftragsverarbeitern gehört.

Was Auditoren fragen werden

Unterschiedliche Auditoren betrachten den Exit von Auftragsverarbeitern aus unterschiedlichen Perspektiven, aber das Nachweispaket sollte für alle ausreichend belastbar sein.

Ein ISO/IEC 27001:2022-Auditor beginnt möglicherweise nicht mit der Frage nach einem “PII deletion certificate”. Er kann mit Geltungsbereich, Anforderungen interessierter Parteien, Lieferantenkontrolle, Erklärung zur Anwendbarkeit, Risikobehandlung und aufbewahrter dokumentierter Information beginnen. Wenn das Löschzertifikat nicht mit diesen Elementen verbunden werden kann, wirkt es wie ein isoliertes Artefakt und nicht wie der Nachweis einer funktionierenden Kontrolle.

Ein PIMS-Auditor wird fragen, ob die Organisation ihre Datenschutzrolle verstanden hat. War sie Verantwortlicher, Auftragsverarbeiter, Unterauftragsverarbeiter oder Cloud-PII-Processor? Basierte der Exit auf einer dokumentierten Kundenweisung? Wurden Pflichten an Unterauftragsverarbeiter weitergegeben? Wurden Nachweise im richtigen Register gespeichert? Wurden Ausnahmen begründet?

Ein DORA-Prüfer wird fragen, ob der Service im IKT-Informationsregister enthalten ist, ob er eine kritische oder wichtige Funktion unterstützt, ob der Vertrag Datenrückgabe und Auditrechte enthielt und ob der Übergang ohne Störung und Kundenschaden erfolgte.

Dasselbe Nachweispaket sollte alle diese Fragen beantworten.

Häufige Fehlermuster

Clarysec sieht bei Prüfungen von Auftragsverarbeiter-Exits wiederholt dieselben Schwächen:

• Verträge verlangen Löschung, definieren aber keine Nachweise.
• Lieferanten stellen generische Löschbestätigungen ohne Systemumfang bereit.
• Backups, Snapshots und unveränderliche Archive werden ignoriert.
• Die Löschung durch Unterauftragsverarbeiter wird angenommen, aber nicht nachgewiesen.
• Kontodeaktivierung wird als Datenlöschung behandelt.
• Die Beschaffung schließt den Lieferanten, bevor die Compliance-Funktion die Nachweise geprüft hat.
• Aufbewahrungsausnahmen sind undokumentiert.
• Entwickler behalten Testexporte nach Ende der ausgelagerten Entwicklung zurück.
• Cloud-Konten werden geschlossen, bevor die Löschbestätigung eingeholt wurde.
• Auditnachweise werden in E-Mails gespeichert, nicht in einem kontrollierten Register.

Das Szenario ausgelagerter Entwicklung ist besonders häufig. Die Outsourced development policy - SME verlangt in Klausel 7.4.1.2:

“Alle von Entwicklern gehaltenen Daten müssen gelöscht werden; Nachweise können angefordert werden.”

Für Entwicklungsteams umfasst dies lokale Datenbestände, Staging-Datenbanken, Debug-Protokolle, Crash Dumps, Screenshots, Support-Exporte, KI-Testprompts und temporäre Migrationsdateien. Wenn der Exit-Workflow für Lieferanten von Entwicklern gehaltene Daten ignoriert, ist er unvollständig.

Checkliste für den Exit von Auftragsverarbeitern

Ein robuster Exit-Prozess für Auftragsverarbeiter muss nicht komplex sein, aber er muss konsequent durchgeführt werden.

• Exit-Auslöser identifizieren: Beendigung, Ablauf, Kundenweisung, Lieferantenwechsel, Reaktion auf Verstöße, genehmigter Übergang oder Beendigung eines Unterauftragsverarbeiters.
• PIMS-Rolle bestätigen: Verantwortlicher, Auftragsverarbeiter, Unterauftragsverarbeiter, gemeinsam Verantwortlicher oder Cloud-PII-Processor.
• Lieferantendatensatz verknüpfen: Vertrag, Serviceverantwortlicher, Geschäftsfunktion, Kritikalität und Datenkategorien.
• PII-Geltungsbereich identifizieren: Produktion, Backups, Protokolle, Exporte, Support-Tickets, Analytics, Testdaten und Unterauftragsverarbeiter.
• Schriftliche Weisungen erteilen: Rückgabe, Übermittlung, Löschung, Entsorgung oder Aufbewahrungsausnahme.
• Nachweise einholen: Löschzertifikat, Vernichtungszertifikat, Protokolle, Bescheinigung von Unterauftragsverarbeitern und Nachweis der Zugriffsschließung.
• Nachweise in REG08 oder REG12 erfassen: Ablageort des Nachweises, Datum, Verfahren, verantwortliche Person und Prüfer.
• Vor Abschluss verifizieren: Nachweise mit Datenumfang, Vertrag und Kundenweisungen abgleichen.
• Ausnahmen eskalieren: fehlende Nachweise, verzögerter Ablauf von Backups, strittige Aufbewahrung, nicht kooperativer Lieferant oder verbleibende Zugriffsrechte.
• Verbesserung zurückführen: Vertragsvorlagen, Lieferantenrisikoeinstufung, Datenaufbewahrungsplan, Auditplan und Managementberichterstattung aktualisieren.

So wirken Zenith Blueprint, Zenith Controls und der Clarysec-Richtliniensatz zusammen. Der Blueprint zeigt, wo die Kontrolle in die Umsetzungsreise gehört. Die Richtlinien definieren das erforderliche Verhalten. Zenith Controls ordnet die Kontrollbeziehung über ISO/IEC 27002:2022, GDPR, DORA, NIS2, NIST und Auditerwartungen hinweg zu.

Die Botschaft an das Leitungsorgan

Der Exit von Auftragsverarbeitern ist kein administrativer Schritt am Ende eines Vertrags. Er ist ein Praxistest für Datenschutz-Governance, Lieferantenmanagement, Cloud-Sicherheit, IKT-Resilienz und Disziplin bei Auditnachweisen.

Ein Löschzertifikat ist nur dann wertvoll, wenn es verknüpft ist mit:

• einer bekannten Lieferantenbeziehung
• einem definierten Datenumfang
• einer vertraglichen oder kundenseitigen Weisung
• einem sicheren Lösch- oder Entsorgungsverfahren
• Nachweisen zur Weitergabe von Pflichten an Unterauftragsverarbeiter
• Schließung von Zugriffen
• Umgang mit Backups und Archiven
• einem kontrollierten Nachweisregister
• abschließender Verifikation der Compliance

Ohne diese Kette verlässt sich die Organisation genau in dem Moment auf Vertrauen, in dem sie sich auf Nachweise stützen sollte.

Nächste Schritte mit Clarysec

Wenn Ihre Organisation SaaS-, Cloud-, Payroll-, HR-, Finanz-, Support-, Entwicklungs- oder Managed-ICT-Anbieter nutzt, prüfen Sie Ihren Exit-Workflow für Auftragsverarbeiter, bevor die nächste Kündigungsmitteilung versendet wird.

Clarysec kann Sie bei der Umsetzung eines praktikablen, auditbereiten Exit-Modells für Auftragsverarbeiter unterstützen mit:

• Zenith Blueprint: An Auditor’s 30-Step Roadmap, um Lieferanten-Exit, Löschung und Entsorgung in den richtigen Umsetzungsschritten zu verorten.
• Zenith Controls: The Cross-Compliance Guide, um Lieferantenvereinbarungen, Informationslöschung und sichere Entsorgung über ISO/IEC 27002:2022, GDPR, DORA, NIS2, NIST und Auditerwartungen hinweg zuzuordnen.
• Processor, Subprocessor and Third-Party Privacy Management Policy und PII Retention, Deletion and Disposal Policy, um REG08-Nachweise operativ umzusetzen.
• Third party and supplier security policy, Data Retention and Disposal Policy und Cloud PII Processor Policy, um Exit-Nachweise durchsetzbar zu machen.

Ihre nächste Maßnahme ist einfach: Wählen Sie einen kürzlich beendeten Lieferanten aus und erstellen Sie rückwirkend ein Exit-Nachweispaket. Wenn Sie Rückgabe, Löschung, Bestätigung von Unterauftragsverarbeitern und abschließende Verifikation nicht belegen können, ist das Ihr erster Punkt für Abhilfemaßnahmen.

Clarysec kann Ihnen helfen, diese Lücke in eine wiederholbare Kontrolle für den Exit von Auftragsverarbeitern zu überführen, bevor ein Auditor, eine Aufsichtsbehörde oder ein Kunde danach fragt.