Kurzantwort
Sub-Verarbeitungen sind keine eigenständige Kategorie der DSGVO. Der Begriff bezeichnet hier ein organisatorisches und technisches Strukturprinzip im Verzeichnis von Verarbeitungstätigkeiten: Eine zentrale Stammverarbeitung bildet den gemeinsamen Kern eines Prozesses ab. Lokale oder use-case-spezifische Varianten werden als untergeordnete Ausprägungen dieser Stammverarbeitung geführt.
Ein solches Modell kann insbesondere für Konzerne relevant sein. Viele Prozesse werden in mehreren Gesellschaften, Ländern oder Standorten in vergleichbarer Weise durchgeführt, unterscheiden sich jedoch in einzelnen Punkten. Unverbundene Kopien können unter diesen Voraussetzungen zu Inkonsistenzen führen. Eine Stammverarbeitung mit zugeordneten Sub-Verarbeitungen ermöglicht es dagegen, gemeinsame Standards, lokale Abweichungen, Verantwortlichkeiten, Freigaben, Versionen, Statusangaben und die Stilllegung nicht mehr benötigter Varianten miteinander zu verbinden.
Lokale Abweichungen im Konzern-RoPA
In Konzernen bestehen zahlreiche Verarbeitungstätigkeiten, die in mehreren Gesellschaften oder an mehreren Standorten in ähnlicher Form durchgeführt werden. Dies betrifft beispielsweise HR-Prozesse, Bewerbermanagement, CRM, Mieterkommunikation, Facility-Prozesse, Lieferantenmanagement, Besucherregistrierung, Schulungsverwaltung, IT-Support, Fuhrparkverwaltung, Hinweisgebersysteme und Marketingprozesse.
Der gemeinsame Prozesskern ist dabei häufig vergleichbar. Bei näherer Betrachtung können jedoch erhebliche Unterschiede bestehen. Eine Gesellschaft nutzt einen lokalen Dienstleister, während eine andere auf einen konzernweit eingesetzten Anbieter zurückgreift. An einzelnen Standorten werden zusätzliche Daten verarbeitet oder weitere Empfänger einbezogen. Aufbewahrungsfristen können aufgrund lokaler Anforderungen voneinander abweichen. Auch der Zweckzuschnitt, die eingesetzten Anwendungen, die Rechtsgrundlagen oder die internen Freigabeprozesse müssen nicht in allen Gesellschaften identisch sein.
Nicht jede dieser Abweichungen erfordert zwangsläufig eine vollständig eigenständige Verarbeitungstätigkeit. Sie muss jedoch so strukturiert dokumentiert werden, dass der gemeinsame Standard und die jeweilige lokale Besonderheit nachvollziehbar bleiben.
In der Praxis wird eine bestehende Verarbeitungstätigkeit häufig kopiert und anschließend für die jeweilige Gesellschaft oder den betreffenden Standort angepasst. Dieses Vorgehen kann zunächst den Dokumentationsaufwand reduzieren. Mit zunehmender Zahl der Kopien wird es jedoch schwieriger, den Zusammenhang zwischen dem ursprünglichen Prozess und den lokalen Varianten zu erkennen und dauerhaft zu steuern.
Risiken unverbundener RoPA-Kopien
Eine Kopie einer bestehenden Verarbeitungstätigkeit lässt sich regelmäßig schnell erstellen. Der vorhandene Eintrag wird übernommen und in einzelnen Feldern an die lokalen Gegebenheiten angepasst. Problematisch kann dieses Vorgehen werden, sobald sich die zentrale Beschreibung oder eine andere gemeinsame Vorgabe ändert.
Eine unverbundene Kopie enthält in der Regel keine belastbare Information darüber, auf welchem Stammprozess sie beruht. Wird beispielsweise eine zentrale Datenkategorie geändert, muss zunächst ermittelt werden, welche lokalen Einträge von dieser Änderung betroffen sind. Entsprechendes gilt beim Austausch eines Dienstleisters, bei der Anpassung einer Löschfrist, bei Änderungen an technischen und organisatorischen Maßnahmen oder bei der Überarbeitung einer zentralen Prozessbeschreibung.
Bestehen zahlreiche ähnliche Kopien, kann mit der Zeit unklar werden, welcher Eintrag den konzernweiten Standard abbildet und welche Einträge lediglich lokale Abweichungen enthalten. Damit entsteht nicht nur ein Dokumentationsproblem. Betroffen sind insbesondere die Steuerung, die Aktualisierung, das Reporting und die Nachweisführung.
Nach Art. 30 DSGVO muss das Verzeichnis von Verarbeitungstätigkeiten unter anderem Angaben zu den Zwecken der Verarbeitung, den Kategorien betroffener Personen und personenbezogener Daten, den Empfängern, etwaigen Drittlandübermittlungen, den vorgesehenen Löschfristen und, soweit möglich, eine allgemeine Beschreibung der technischen und organisatorischen Maßnahmen enthalten. Das Verzeichnis ist schriftlich zu führen, wobei auch ein elektronisches Format zulässig ist, und der zuständigen Aufsichtsbehörde auf Anfrage zur Verfügung zu stellen.
Vor diesem Hintergrund ist nicht nur die Vollständigkeit der einzelnen Einträge, sondern auch die Struktur des Verzeichnisses von Bedeutung. Beschreiben mehrere Kopien denselben Prozess in voneinander abweichender Weise, kann es gegenüber Management, Datenschutzbeauftragten oder Aufsichtsbehörden schwierig werden, den tatsächlich geltenden Stand nachvollziehbar darzustellen.
Begriff der Sub-Verarbeitung im RoPA
Der Begriff „Sub-Verarbeitung“ wird in diesem Beitrag bewusst in einem operativen Sinn verwendet. Gemeint ist weder eine Unterauftragsverarbeitung durch einen weiteren Auftragsverarbeiter noch eine neue rechtliche Kategorie der DSGVO.
Eine Sub-Verarbeitung bezeichnet vielmehr eine untergeordnete Variante einer Stammverarbeitung innerhalb des Verzeichnisses von Verarbeitungstätigkeiten.
Die Stammverarbeitung beschreibt insbesondere den gemeinsamen Kern des Prozesses:
- den übergeordneten Zweck,
- den Hauptprozess,
- die regelmäßig betroffenen Personengruppen,
- typische Datenkategorien,
- zentrale Systeme,
- Standardempfänger,
- typische Dienstleister,
- grundlegende technische und organisatorische Maßnahmen,
- die Standardlöschlogik,
- zentrale Risiken,
- zentrale Verantwortlichkeiten sowie
- vorgesehene Standardprüfungen und Freigaben.
Die Sub-Verarbeitung bildet demgegenüber die kontrollierte Abweichung vom gemeinsamen Standard ab. Sie kann sich insbesondere beziehen auf:
- eine lokale Gesellschaft,
- einen Standort,
- ein bestimmtes Land,
- einen Fachbereich,
- einen zusätzlichen Use Case,
- einen abweichenden Dienstleister,
- eine zusätzliche Datenkategorie,
- eine andere lokale Aufbewahrungsfrist,
- einen zusätzlichen Empfänger,
- einen lokalen Prozessschritt,
- einen abweichenden Status,
- eine lokale Freigabe oder
- eine ergänzende lokale Maßnahme.
Anstelle mehrerer unverbundener Kopien entsteht damit eine Stammverarbeitung, der die jeweiligen lokalen oder use-case-spezifischen Varianten nachvollziehbar zugeordnet sind.
Beispiel: Bewerbermanagement im Konzern
Beim Bewerbermanagement ist der gemeinsame Prozesskern in vielen Gesellschaften vergleichbar. Bewerbungen werden entgegengenommen, geprüft, mit den zuständigen Fachbereichen abgestimmt, dokumentiert und nach Ablauf der jeweils maßgeblichen Fristen gelöscht. Betroffen sind Bewerberinnen und Bewerber. Zu den typischerweise verarbeiteten Daten gehören Kontaktinformationen, Angaben aus Lebensläufen, Qualifikationsnachweise, Gesprächsnotizen und Kommunikationsdaten. Regelmäßig sind ein Bewerbermanagementsystem, die Personalabteilung, die beteiligten Fachbereiche und gegebenenfalls externe Dienstleister eingebunden.
Dieser gemeinsame Kern kann in einer Stammverarbeitung dokumentiert werden. Die konkrete Ausgestaltung kann sich jedoch zwischen den Gesellschaften unterscheiden.
So kann eine deutsche Gesellschaft das zentrale Bewerbermanagementsystem verwenden, während in Frankreich zusätzlich ein lokaler Dienstleister eingebunden wird. In den USA kann eine andere Interviewplattform zum Einsatz kommen. Eine Gesellschaft bewahrt bestimmte Unterlagen aufgrund lokaler arbeitsrechtlicher Anforderungen länger auf. Eine Business Unit erhebt zusätzliche Portfolio-Unterlagen. An einem Standort werden für bestimmte Rollen Sicherheitsüberprüfungen durchgeführt. In einem Land gelten abweichende Informationspflichten, während in einer anderen Gesellschaft zusätzlich ein Betriebsratsprozess vorgesehen ist.
Diese Unterschiede begründen nicht in jedem Fall zehn vollständig eigenständige Verarbeitungstätigkeiten. Soweit der gemeinsame Prozesskern weiterhin tragfähig ist, können sie als Varianten der Stammverarbeitung geführt werden. Durch die Zuordnung als Sub-Verarbeitungen bleibt erkennbar, welche Angaben konzernweit gelten und an welchen Stellen lokale Abweichungen bestehen.
| Bewertungsfrage | Unverbundene Kopie | Stammverarbeitung mit Sub-Verarbeitung |
|---|---|---|
| Gemeinsamer Prozesskern | Wird mehrfach beschrieben. | Wird einmal in der Stammverarbeitung gepflegt. |
| Lokale Abweichung | Ist häufig nur innerhalb der Kopie erkennbar. | Wird ausdrücklich als Variante dokumentiert. |
| Änderungen am Standard | Müssen in den betroffenen Kopien einzeln nachgezogen werden. | Können zentral gesteuert und für die Varianten geprüft werden. |
| Lokale Verantwortung | Ist häufig unklar oder nur in Freitextfeldern enthalten. | Kann einer eigenen lokalen Rolle oder einem Owner zugeordnet werden. |
| Reporting | Erfordert die nachträgliche Konsolidierung mehrerer Einträge. | Varianten bleiben dem jeweiligen Stammprozess zugeordnet. |
| Auditfähigkeit | Historie und Entscheidungen verteilen sich auf mehrere Einträge. | Abweichungen, Prüfungen und Freigaben bleiben miteinander verbunden. |
| Deaktivierung und Archivierung | Nicht mehr genutzte Kopien bleiben häufig bestehen. | Varianten können gezielt deaktiviert oder archiviert werden. |
| Managementsicht | Zeigt zahlreiche ähnliche Einträge ohne übergeordnete Zuordnung. | Zeigt einen gemeinsamen Prozess mit kontrollierten Ausprägungen. |
Sub-Verarbeitungen dienen damit nicht dazu, den erforderlichen Dokumentationsumfang zu reduzieren. Sie sollen die Dokumentation so strukturieren, dass gemeinsame Standards und lokale Besonderheiten steuerbar bleiben.
Vererbung und lokale Pflege von Feldern
Nicht sämtliche Angaben einer Verarbeitungstätigkeit müssen in jeder lokalen Variante erneut gepflegt werden. Bei konzernweit vergleichbaren Prozessen kann es sinnvoll sein, bestimmte Informationen aus der Stammverarbeitung zu übernehmen. Andere Angaben sollten lokal ergänzt, überprüft oder überschrieben werden können.
| Feldgruppe | Typische Behandlung | Begründung |
|---|---|---|
| Prozessname und Grundzweck | Zentral vererben | Unterstützt eine einheitliche Struktur und Wiedererkennbarkeit. |
| Beschreibung des Standardprozesses | Zentral vererben | Vermeidet voneinander abweichende Kopien derselben Beschreibung. |
| Standarddatenkategorien | Vererben und lokal ergänzen | Zusätzliche lokale Datenkategorien müssen erkennbar bleiben. |
| Betroffenengruppen | Vererben und lokal ergänzen | Die Gruppen sind häufig vergleichbar, aber nicht zwingend vollständig identisch. |
| Zentrales System | Zentral vererben | Konzernweit eingesetzte Systeme müssen nicht mehrfach gepflegt werden. |
| Lokale Systeme | Lokal ergänzen | Abweichende Anwendungen sollen ausdrücklich dokumentiert werden. |
| Standarddienstleister | Zentral vererben | Vermeidet eine mehrfache Pflege derselben Dienstleisterangaben. |
| Lokale Dienstleister | Lokal ergänzen | Kann für Auftragsverarbeitung, Drittlandtransfers und Risiken relevant sein. |
| Rechtsgrundlagen | Teilweise übernehmen und lokal prüfen | Lokale Besonderheiten können eine gesonderte Bewertung erfordern. |
| Löschfristen | Vererben und lokal überschreibbar ausgestalten | Nationale oder organisatorische Unterschiede müssen abgebildet werden können. |
| Technische und organisatorische Maßnahmen | Vererben und lokal ergänzen | Zentrale Maßnahmen können durch lokale Vorkehrungen ergänzt werden. |
| Risiken | Zentrale und lokale Risiken miteinander verbinden | Konzernweite und lokale Risikolagen sind voneinander zu unterscheiden. |
| Owner | Lokal zuweisen | Die operative Verantwortung muss für die jeweilige Variante feststehen. |
| Freigabe | Je nach Prozess lokal oder zentral | Der Freigabestatus kann zwischen den Varianten abweichen. |
| Status | Lokal führen | Eine Variante kann aktiv, geplant, deaktiviert oder archiviert sein. |
| Review-Termin | Lokal oder zentral festlegen | Die Zuständigkeit richtet sich nach Risikoprofil und Organisationsmodell. |
Maßgeblich ist nicht, möglichst viele Felder zentral zu vererben. Vielmehr ist zu bestimmen, welche Angaben tatsächlich einen verbindlichen Standard darstellen und welche Informationen einer lokalen Prüfung und Steuerung bedürfen.
Anforderungen an lokale Varianten
Lokale Varianten sollten nicht als frei bearbeitbare Kopien geführt werden. Erforderlich ist vielmehr eine Struktur, anhand derer der Bezug zur Stammverarbeitung, die konkrete Abweichung und die hierfür bestehende Verantwortung nachvollzogen werden können.
Eine Sub-Verarbeitung sollte deshalb mindestens erkennen lassen:
- welche Stammverarbeitung zugrunde liegt,
- welche Gesellschaft, welcher Standort oder welcher Fachbereich betroffen ist,
- welche Felder vom konzernweiten Standard abweichen,
- aus welchem Grund die Abweichung erforderlich ist,
- wer die Abweichung geprüft hat,
- wer die Freigabe erteilt hat,
- welche zusätzlichen Risiken durch die Abweichung entstehen können,
- welche lokalen Maßnahmen vorgesehen sind,
- zu welchem Zeitpunkt eine erneute Überprüfung erfolgen soll und
- ob die Variante geplant, in Prüfung, aktiv, deaktiviert oder archiviert ist.
Ohne diese Angaben besteht das Risiko, dass lediglich eine weitere Kopie mit einer abweichenden Bezeichnung entsteht. Erst die dokumentierte Zuordnung, Begründung und Freigabe macht aus der lokalen Abweichung ein steuerbares Governance-Objekt.
Use-Case-spezifische Abweichungen
Nicht jede Variante ist an ein bestimmtes Land, eine Gesellschaft oder einen Standort gebunden. Abweichungen können auch aufgrund eines besonderen Use Cases entstehen.
Ein CRM-Prozess kann beispielsweise im Standard der Kundenbetreuung dienen. Eine Business Unit nutzt denselben Prozess zusätzlich für ein Veranstaltungsprogramm, während eine andere Einheit ihn für die Kommunikation mit Partnern einsetzt. An einem Standort kann eine zusätzliche Datenquelle genutzt werden. Ein Projektteam kann den bestehenden Prozess um Analysefunktionen ergänzen.
In solchen Fällen ist zu prüfen, ob weiterhin eine Ausprägung des bestehenden Prozesskerns vorliegt oder ob eine eigenständige Verarbeitungstätigkeit dokumentiert werden sollte. Maßgeblich sind insbesondere der Zweck, die verarbeiteten Daten, die Empfänger, die Risikolage und die organisatorische Verantwortung.
Es wäre daher weder sachgerecht, jede Abweichung automatisch als Sub-Verarbeitung einzuordnen, noch jede Besonderheit durch eine vollständig neue und unverbundene Kopie abzubilden. Entscheidend ist, ob der gemeinsame Prozesskern weiterhin trägt und die Abweichung hinreichend bestimmt beschrieben, geprüft und freigegeben werden kann.
Abgrenzung zur eigenständigen Verarbeitungstätigkeit
Sub-Verarbeitungen dürfen nicht dazu führen, wesentliche Unterschiede zwischen Verarbeitungstätigkeiten zu verdecken. Eine eigenständige Verarbeitung kann insbesondere dann in Betracht kommen, wenn:
- sich der Zweck wesentlich unterscheidet,
- andere Betroffenengruppen einbezogen werden,
- zusätzliche Datenkategorien mit einem höheren Risiko verarbeitet werden,
- ein anderes System oder ein anderer Dienstleister die Risikolage wesentlich verändert,
- andere Empfänger eingebunden werden oder
- die lokale Variante organisatorisch einen eigenständigen Prozess darstellt.
Wird ein HR-System im Standard für das Bewerbermanagement genutzt, führt eine lokale Gesellschaft damit aber zusätzlich automatisierte Eignungsbewertungen unter Einsatz von KI durch, kann dies je nach konkreter Ausgestaltung über eine geringfügige Abweichung hinausgehen. In einem solchen Fall kann eine eigenständige Verarbeitungstätigkeit oder zumindest eine deutlich abgegrenzte Sub-Verarbeitung mit eigener Risikobewertung und gesonderter Freigabe erforderlich sein.
Maßgeblich ist somit die fachliche Abgrenzung. Die administrative Vereinfachung kann für die Entscheidung, ob eine Variante oder eine eigenständige Verarbeitungstätigkeit vorliegt, nicht allein ausschlaggebend sein.
Freigabe lokaler Abweichungen
Eine lokale Variante sollte nicht ohne dokumentierte Prüfung in den operativen Status überführt werden. Der erforderliche Freigabeprozess muss nicht zwangsläufig umfangreich ausgestaltet sein, sollte jedoch klare Zuständigkeiten und Prüfschritte vorsehen.
Ein typischer Ablauf kann folgende Schritte umfassen:
- Der lokale Owner beantragt die Abweichung.
- Das System weist aus, welche Felder vom Standard abweichen.
- Die zuständige Datenschutzfunktion prüft die datenschutzrechtliche Relevanz.
- Soweit erforderlich, werden Legal, IT Security, der Datenschutzbeauftragte oder weitere zuständige Stellen einbezogen.
- Festgestellte Risiken und erforderliche Maßnahmen werden dokumentiert.
- Die Variante wird freigegeben, mit Bedingungen freigegeben oder zur Überarbeitung zurückgegeben.
- Der Variante werden ein Status und ein Review-Termin zugeordnet.
- Die Abweichung bleibt mit der zugrunde liegenden Stammverarbeitung verbunden.
Auf diese Weise wird nicht nur eine Änderung am Datensatz dokumentiert. Vielmehr bleibt auch nachvollziehbar, auf welcher Grundlage die Abweichung geprüft und freigegeben wurde.
Statusmodell für Sub-Verarbeitungen
Sub-Verarbeitungen sollten über einen eigenen Status verfügen. Ohne ein solches Statusmodell kann nicht zuverlässig unterschieden werden, ob eine Variante lediglich vorbereitet, bereits geprüft, operativ eingesetzt oder nicht mehr genutzt wird.
| Status | Bedeutung |
|---|---|
| Entwurf | Die Variante wird vorbereitet und ist noch nicht gültig. |
| In Prüfung | Datenschutz, Legal oder andere zuständige Rollen prüfen die Abweichung. |
| Zurückgegeben | Angaben fehlen oder die Abweichung ist nicht hinreichend begründet. |
| Freigegeben | Die Variante ist aktiv und darf verwendet werden. |
| Freigegeben mit Bedingungen | Die Variante ist aktiv, unterliegt aber bestimmten Maßnahmen oder Fristen. |
| In Review | Die Variante wird erneut bewertet. |
| Deaktiviert | Die Variante wird nicht mehr genutzt, bleibt aber nachvollziehbar. |
| Archiviert | Die Variante ist historisch relevant, jedoch nicht mehr operativ aktiv. |
| Gelöscht | Die Variante kann entfernt werden, sofern keine rechtlichen oder fachlichen Nachweispflichten entgegenstehen. |
Ein Konzern-RoPA kann nicht nur durch die fortlaufende Anlage neuer Einträge unübersichtlich werden. Entsprechendes gilt für Varianten, die operativ nicht mehr benötigt werden, deren Status aber nicht angepasst wurde. Ein nachvollziehbares Statusmodell ist deshalb Voraussetzung für die laufende Pflege des Verzeichnisses.
Deaktivierung, Archivierung und Löschung
Nicht mehr relevante Varianten sollten nicht dauerhaft als aktive Verarbeitungstätigkeiten geführt werden. Eine unmittelbare Löschung ist jedoch ebenfalls nicht in jedem Fall sachgerecht.
Zunächst ist zu prüfen, ob die betreffende Variante tatsächlich operativ genutzt wurde. Wurde sie nie eingesetzt, kann eine Löschung in Betracht kommen, sofern weder rechtliche Nachweispflichten noch interne Gründe für eine weitere Aufbewahrung bestehen.
Wurde die Variante dagegen produktiv genutzt, ist eine Deaktivierung oder Archivierung regelmäßig besser geeignet. Auf diese Weise bleibt nachvollziehbar, dass und in welchem Zeitraum die Variante bestand, wann sie beendet wurde, welche Daten betroffen waren, welche Löschfristen weiterhin zu berücksichtigen sind und welche Entscheidungen im Zusammenhang mit der Verarbeitung getroffen wurden.
Eine Überprüfung der Sub-Verarbeitung kommt insbesondere in Betracht, wenn:
- die betreffende Gesellschaft den Prozess nicht mehr nutzt,
- das eingesetzte System abgeschaltet wurde,
- ein Dienstleister gewechselt wurde,
- der Zweck entfallen ist,
- der zugrunde liegende Use Case beendet wurde,
- eine bisher lokale Abweichung in den konzernweiten Standard übernommen wurde,
- die Variante durch eine neue Variante ersetzt wurde oder
- im Rahmen eines Audits eine veraltete Struktur festgestellt wurde.
Die Deaktivierung ist damit Teil der Governance und nicht lediglich eine Maßnahme zur formalen Bereinigung des Verzeichnisses.
Anforderungen an das Reporting
Für einen Konzern-Datenschutzbeauftragten oder eine zentrale Datenschutzfunktion ist eine Auflistung zahlreicher nahezu identischer Verarbeitungstätigkeiten regelmäßig nur eingeschränkt aussagekräftig. Erforderlich ist vielmehr eine Auswertung, aus der hervorgeht:
- welche Prozesse konzernweit standardisiert sind,
- welche Gesellschaften oder Standorte vom Standard abweichen,
- welche Abweichungen ein erhöhtes Risiko aufweisen,
- welche Varianten noch nicht freigegeben wurden,
- bei welchen Varianten lokale Maßnahmen überfällig sind,
- welche Einträge veraltet sind und
- welche lokalen Abweichungen gegebenenfalls in den konzernweiten Standard übernommen werden sollten.
Ein Bericht zum Bewerbermanagement sollte deshalb nicht lediglich mehrere unverbundene Verarbeitungstätigkeiten nebeneinanderstellen. Er sollte den Stammprozess, die aktiven Varianten, die jeweiligen Abweichungen, den Risiko- und Freigabestatus, überfällige Reviews, offene Maßnahmen, abgelaufene Varianten und Gesellschaften ohne aktuelle Prüfung ausweisen.
Ein solches Reporting setzt voraus, dass Stammverarbeitung und Varianten strukturiert miteinander verbunden sind. Erst dann kann das RoPA über die reine Dokumentation hinaus als Steuerungsinstrument genutzt werden.
Verhältnis zu Art. 30 DSGVO
Art. 30 DSGVO verlangt von Verantwortlichen ein Verzeichnis der Verarbeitungstätigkeiten, die ihrer Zuständigkeit unterliegen. Auftragsverarbeiter müssen ein Verzeichnis der Kategorien von Verarbeitungstätigkeiten führen, die sie im Auftrag eines Verantwortlichen durchführen. Das jeweilige Verzeichnis ist der Aufsichtsbehörde auf Anfrage zur Verfügung zu stellen.
Die DSGVO schreibt jedoch kein bestimmtes technisches Datenmodell vor. Insbesondere ergibt sich aus Art. 30 DSGVO nicht, dass jede lokale Abweichung zwingend als vollständig isolierter Eintrag geführt werden muss. Ebenso wenig verlangt die Vorschrift, gleichartige Prozesse durch unverbundene Kopien zu dokumentieren.
Entscheidend ist, dass die tatsächlich relevanten Informationen zutreffend, nachvollziehbar und verfügbar sind. Die EDPB beschreibt das Verzeichnis als Inventar der Verarbeitungsvorgänge, anhand dessen Verantwortlichkeiten und mögliche Risiken erkennbar werden können. Zu den maßgeblichen Angaben gehören unter anderem der Zweck, die Datenkategorien, die Empfänger, etwaige Übermittlungen, Speicher- beziehungsweise Löschfristen und die vorgesehenen Sicherheitsmaßnahmen.
Sub-Verarbeitungen ersetzen daher nicht die Anforderungen aus Art. 30 DSGVO. Sie stellen vielmehr ein mögliches Organisationsmodell dar, um die erforderlichen Informationen in komplexen Konzernstrukturen geordnet abzubilden.
Unterstützung durch Ailance RoPA
Ailance RoPA kann Konzernprozesse als miteinander verbundene Stammverarbeitungen und lokale beziehungsweise use-case-spezifische Varianten abbilden. Die zentrale Stammverarbeitung beschreibt dabei den gemeinsamen Standard. Untergeordnete Sub-Verarbeitungen erfassen die jeweiligen Besonderheiten.
Felder können aus der Stammverarbeitung übernommen, lokal ergänzt oder kontrolliert überschrieben werden. Abweichungen bleiben dadurch erkennbar. Verantwortlichkeiten, Freigaben, Maßnahmen, Statusangaben und Review-Termine können der jeweiligen Variante zugeordnet werden.
Für die Steuerung sind insbesondere drei Ebenen voneinander zu unterscheiden:
Standard
Welche Angaben gelten konzernweit für den gemeinsamen Prozess?
Variante
Welche Angaben gelten für eine bestimmte Gesellschaft, einen Standort oder einen besonderen Use Case abweichend?
Nachweis
Wer hat die Abweichung geprüft, freigegeben, geändert, erneut bewertet oder deaktiviert?
Diese Trennung ist insbesondere für größere Organisationen mit zahlreichen vergleichbaren Prozessen relevant. Probleme im RoPA entstehen häufig nicht allein durch fehlende Einträge, sondern dadurch, dass zwischen ähnlichen Einträgen keine nachvollziehbare Struktur besteht.
Beispiel: Mieterkommunikation
Ein Immobilienkonzern führt eine Verarbeitungstätigkeit zur Mieterkommunikation. Die Stammverarbeitung kann insbesondere folgende Angaben enthalten:
- Kommunikation mit Mieterinnen und Mietern,
- Stammdaten,
- Kontaktdaten,
- Vertragsbezug,
- Bearbeitung von Anliegen,
- Nutzung eines zentralen CRM-Systems,
- eine Standardlöschfrist,
- Standardempfänger und
- zentrale technische und organisatorische Maßnahmen.
Auf lokaler Ebene können hiervon unterschiedliche Varianten bestehen. Eine Gesellschaft nutzt zusätzlich ein lokales Servicecenter. An einem Standort kommt ein weiteres Kommunikationstool zum Einsatz. In einer Region werden besondere Schadensinformationen verarbeitet. Eine Gesellschaft beauftragt einen externen Druckdienstleister, während eine andere eine eigene Mieter-App betreibt.
Diese Besonderheiten können entweder als eigenständige Verarbeitungstätigkeiten oder als klar abgegrenzte Sub-Verarbeitungen dokumentiert werden. Soweit der gemeinsame Prozesskern fortbesteht, ermöglicht die Zuordnung zur Stammverarbeitung eine deutlichere Darstellung des konzernweiten Standards und der jeweiligen lokalen Abweichungen.
Beispiel: Facility-Prozesse
Facility-Prozesse sind aufgrund ihrer standortbezogenen Ausgestaltung besonders anfällig für die Anlage zahlreicher ähnlicher Einträge. Hierzu gehören beispielsweise Besucherregistrierung, Zutrittskontrolle, Videoüberwachung, Schlüsselverwaltung, Parkplatzverwaltung, Reinigungskoordination und Reparaturmeldungen.
Viele Standorte führen diese Prozesse in vergleichbarer Weise durch. Die konkrete Ausgestaltung kann jedoch erheblich voneinander abweichen. An einem Standort wird Videoüberwachung eingesetzt, an einem anderen nicht. Einzelne Standorte nutzen lokale Dienstleister, verarbeiten Kfz-Kennzeichen, führen zusätzliche Zutrittsprotokolle oder setzen eine besondere App ein. Andere Standorte arbeiten weiterhin mit manuellen Listen.
Sub-Verarbeitungen können dazu beitragen, diese Standortvarianten sichtbar zu machen, ohne den gemeinsamen Facility-Prozess in zahlreiche unverbundene Einträge aufzuteilen. Für die zentrale Steuerung bleibt dadurch erkennbar, welche Vorgaben zum Standardprozess gehören und an welchen Standorten aus welchen Gründen davon abgewichen wird.
Beispiel: CRM
CRM-Prozesse sind regelmäßig konzernweit relevant. Die Stammverarbeitung kann die Verwaltung von Kunden und Interessenten beschreiben. Lokale Varianten können unter anderem unterschiedliche Marketingeinwilligungen, lokale Kampagnen, zusätzliche Datenquellen, besondere Empfänger, abweichende Löschlogiken oder unterschiedliche Formen der Systemnutzung abbilden.
Gerade bei CRM-Prozessen besteht bei unverbundenen Kopien das Risiko widersprüchlicher Angaben zu Zwecken, Empfängern, Rechtsgrundlagen und Löschfristen. Eine Stammverarbeitung mit zugeordneten Sub-Verarbeitungen kann dagegen erkennen lassen, welche Angaben konzernweit gelten und welche lokalen oder use-case-spezifischen Besonderheiten geprüft und freigegeben wurden.
Prüffragen für bestehende Konzern-RoPAs
Für eine erste Bestandsaufnahme kann ein Prozess ausgewählt werden, der in mehreren Gesellschaften oder an mehreren Standorten vorkommt. In Betracht kommen beispielsweise Bewerbermanagement, CRM, Mieterkommunikation, Facility Management, Lieferantenmanagement, Besucherregistrierung, Schulungsverwaltung oder IT-Support.
Anschließend sollten insbesondere folgende Fragen geprüft werden:
- Besteht ein klar definierter Stammprozess?
- Welche lokalen oder use-case-spezifischen Varianten existieren?
- Sind die Abweichungen ausdrücklich dokumentiert oder lediglich in voneinander unabhängigen Kopien enthalten?
- Wer hat die jeweiligen Abweichungen geprüft und freigegeben?
- Welche Varianten werden operativ nicht mehr genutzt?
Lassen sich diese Fragen nicht ohne Weiteres beantworten, spricht dies regelmäßig nicht für eine zu geringe Zahl an Verarbeitungstätigkeiten. Vielmehr kann eine fehlende Struktur zwischen den vorhandenen Einträgen vorliegen.
Fazit
Sub-Verarbeitungen können ein geeignetes Strukturmodell für Konzern-RoPAs darstellen, wenn vergleichbare Prozesse in mehreren Gesellschaften, Ländern oder Standorten durchgeführt werden, ohne in allen Einzelheiten identisch zu sein.
Unverbundene Kopien lassen sich zunächst mit geringem Aufwand anlegen. Mit zunehmender Anzahl können sie jedoch zu widersprüchlichen Angaben, unklaren Verantwortlichkeiten, erschwerten Aktualisierungen und einer eingeschränkten Auswertbarkeit führen. Eine Stammverarbeitung mit zugeordneten lokalen oder use-case-spezifischen Varianten kann demgegenüber erkennen lassen, welche Angaben den gemeinsamen Standard bilden und an welchen Stellen geprüfte Abweichungen bestehen.
Eine solche Struktur unterstützt Freigabeprozesse, Reporting, Reviews sowie die Deaktivierung und Archivierung nicht mehr benötigter Varianten. Maßgeblich ist, dass jede Abweichung einem nachvollziehbaren Prozess, einer verantwortlichen Stelle und einem dokumentierten Status zugeordnet werden kann.
Fragen und Antworten
Was sind Sub-Verarbeitungen im Verzeichnis von Verarbeitungstätigkeiten?
Sub-Verarbeitungen sind untergeordnete Varianten einer Stammverarbeitung. Sie bilden lokale oder use-case-spezifische Abweichungen vom gemeinsamen Prozesskern ab. Der Begriff bezeichnet keine eigenständige Kategorie der DSGVO, sondern ein mögliches Strukturmodell für Konzern-RoPAs.
Sind Sub-Verarbeitungen dasselbe wie Unterauftragsverarbeitung?
Nein. Mit Sub-Verarbeitungen sind in diesem Beitrag weder Subprocessor noch Unterauftragsverarbeiter gemeint. Der Begriff bezeichnet Varianten einer Verarbeitungstätigkeit innerhalb eines strukturierten RoPA-Modells.
Warum können Sub-Verarbeitungen für Konzerne hilfreich sein?
Viele Prozesse werden in Konzernen in ähnlicher, aber nicht vollständig identischer Form durchgeführt. Sub-Verarbeitungen ermöglichen es, einen gemeinsamen Stammprozess und kontrollierte lokale Abweichungen miteinander zu verbinden, ohne für jede Variante eine unverbundene Kopie anzulegen.
Wann sollte eine Sub-Verarbeitung anstelle einer Kopie verwendet werden?
Eine Sub-Verarbeitung kommt in Betracht, wenn der gemeinsame Prozesskern erhalten bleibt und lediglich einzelne Angaben lokal oder use-case-spezifisch abweichen. Dies kann beispielsweise lokale Dienstleister, zusätzliche Datenkategorien, abweichende Fristen, lokale Systeme oder besondere Freigaben betreffen.
Wann ist eine eigene Verarbeitung besser als eine Sub-Verarbeitung?
Eine eigenständige Verarbeitung kann erforderlich sein, wenn sich insbesondere der Zweck, die Risikolage, das eingesetzte System, die Datenkategorien, die Empfänger oder die organisatorische Verantwortung so wesentlich unterscheiden, dass der ursprüngliche Prozesskern nicht mehr tragfähig ist.
Welche Felder sollten aus der Stammverarbeitung übernommen werden?
Typischerweise können Prozessname, Grundzweck, Standardbeschreibung, zentrale Systeme, Standarddatenkategorien, Standarddienstleister, zentrale technische und organisatorische Maßnahmen sowie die Standardlöschlogik übernommen werden. Ob eine Übernahme sachgerecht ist, muss für die jeweilige Feldgruppe geprüft werden.
Welche Informationen gehören in eine lokale Variante?
Eine lokale Variante sollte insbesondere die betroffene Gesellschaft, den Standort oder den Use Case, die abweichenden Felder, den Grund der Abweichung, die zuständigen Personen, Risiken, Maßnahmen, Freigaben, Statusangaben und den vorgesehenen Review-Termin enthalten.
Wie sollten lokale Abweichungen freigegeben werden?
Eine lokale Abweichung sollte beantragt, fachlich geprüft, dokumentiert und freigegeben werden. Je nach Art und Risiko der Abweichung können Datenschutz, Legal, IT Security, der Datenschutzbeauftragte oder weitere zuständige Stellen einzubeziehen sein. Die Variante sollte der zugrunde liegenden Stammverarbeitung zugeordnet bleiben.
Wann sollten Sub-Verarbeitungen deaktiviert werden?
Eine Deaktivierung ist insbesondere zu prüfen, wenn die lokale Variante nicht mehr genutzt wird, ihr Zweck entfallen ist, ein System abgeschaltet wurde, ein Dienstleister gewechselt wurde oder die bisherige Abweichung in den konzernweiten Standard übernommen wurde.
Sollten Sub-Verarbeitungen gelöscht oder archiviert werden?
Wurde eine Variante operativ genutzt, ist eine Archivierung oder Deaktivierung regelmäßig besser geeignet als eine unmittelbare Löschung. Dadurch bleiben frühere Entscheidungen, Löschfristen und weitere Nachweise nachvollziehbar. Eine Löschung kann insbesondere dann in Betracht kommen, wenn die Variante nie produktiv eingesetzt wurde und keine rechtlichen oder fachlichen Aufbewahrungsgründe bestehen.
Wie kann Ailance RoPA Sub-Verarbeitungen unterstützen?
Ailance RoPA kann Stammverarbeitungen, lokale Varianten, übernommene Felder, Abweichungen, Verantwortlichkeiten, Freigaben, Maßnahmen, Statusangaben und Reviews miteinander verbinden. Dadurch können gemeinsame Standards und lokale Besonderheiten innerhalb des Konzern-RoPA strukturiert abgebildet werden.
Was ist der wesentliche Vorteil von Sub-Verarbeitungen?
Der wesentliche Vorteil liegt in der nachvollziehbaren Verbindung zwischen Standard und Abweichung. Das RoPA zeigt damit nicht lediglich mehrere ähnliche Prozesse, sondern auch, welche Variante in welchen Punkten vom Standard abweicht, aus welchem Grund dies erfolgt und wer die Abweichung geprüft und freigegeben hat.
German 
English 
Italian 
French