Kitabı oku: «Datenschutz mit bewährten Methoden des Risikomanagements»
Datenschutz mit bewährten Methoden des Risikomanagements
Datenschutz
mit bewährten Methoden des Risikomanagements
Handreichung
Wolfgang Gaess
Fachmedien Recht und Wirtschaft | dfv Mediengruppe | Frankfurt am Main
Bibliografische Information der Deutschen Nationalbibliothek
Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.d-nb.de abrufbar.
ISBN 978-3-8005-1731-2

© 2020 Deutscher Fachverlag GmbH, Fachmedien Recht und Wirtschaft, Frankfurt am Main
www.ruw.de
Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Jede Verwertung außerhalb der engen Grenzen des Urheberrechtsgesetzes ist ohne Zustimmung des Verlages unzulässig und strafbar. Das gilt insbesondere für Vervielfältigungen, Bearbeitungen, Übersetzungen, Mikroverfilmungen und die Einspeicherung und Verarbeitung in elektronischen Systemen.
Druck: WIRmachenDRUCK GmbH, Backnang
Printed in Germany
Aus der Nessel Gefahr pflücken wir die Blume Sicherheit.
“William Shakespeare”
Vorwort
Die Maxime der Funktionsfähigkeit stammt u.a. aus dem Risikomanagement im hoch regulierten Finanzsektor. Insbesondere die Haftung von Geschäftsführung und Aufsichtsrat wirkt mithin höchst motivierend auf diese wichtigen Akteure. Ferner sind die Prüfungszyklen durch Interne Revision, Wirtschaftsprüfer und Finanzaufsicht zu eng getaktet als dass hier „auf Lücke“ gesetzt werden könnte.
Die Übertragung der Erfahrungswerte und der Herangehensweise der letzten Dekade (seit der Finanzkrise) auf die relativ ähnlich gelagerte Arbeit im Datenschutz war maßgebliche Motivation für diese Handreichung.
---
Ich möchte mich an dieser Stelle bei allen Mandanten, Partnern und Kollegen bedanken, die mich mit wichtigen Anmerkungen und Hinweisen unterstützt haben. In gleichem Maße gilt mein Dank an Frau und Sohn für die erduldete Abwesenheit.
| Eschborn, 2. Januar 2020 | Wolfgang Gaess |
Inhaltsverzeichnis
1 Deckblatt
2 Titel
3 Impressum
4 Vorwort
5 Abkürzungsverzeichnis
6 Abbildungsverzeichnis
7 Tabellenverzeichnis
8 I. Methodik und Aufbau 1. Ausgangslage der DSGVO 2. Operationalisierung 3. Aufbau der Kapitel 4. Das Modell der “Three Lines of Defense” a) Modell der drei Verteidigungslinien b) „Außendatenschutz“ und „Papershield“
9 II. Datenschutzmanagement 1. Prozessdesign a) Datenschutzmanagementsystem b) Datenschutzkonzept c) Aufgaben, Rollen & Verantwortlichkeiten d) Problemfelder bei Anwendung des 3LoDM e) Verantwortung und Haftung f) Stellen- und Aufgabenbeschreibung g) Kontrollplan 2. Dokumentation 3. Technische Anpassung 4. Change 5. Vertrag
10 III. Verarbeitungsverzeichnis 1. Prozessdesign a) Organisation b) Ausgangspunkt für die Verarbeitungen c) Aktualisierungspflichten d) Startpunkt Datenschutzfolgenabschätzung 2. Dokumentation 3. Technische Anpassung 4. Change 5. Vertrag
11 IV. Datenschutzfolgenabschätzung 1. Prozessdesign a) Ziel und Zweck b) Prüfungsschritte und Prozessdesign 2. Dokumentation 3. Technische Anpassung 4. Change 5. Vertrag
12 V. Betroffenenrechte 1. Prozessdesign a) Sinn und Zweck: b) Informationspflichten c) Reaktionspflichten d) Recht auf Datenübertragbarkeit e) Weitere Betroffenenrechte 2. Dokumentation 3. Technische Anpassung 4. Change 5. Vertrag
13 VI. Datenpannen – Incident Management 1. Prozessdesign a) Sinn & Zweck b) Dienstleister 2. Dokumentation 3. Technische Anpassung a) Identifikations-Tools b) Dokumentations-Tool c) Change d) Vertrag
14 VII. Technisch-organisatorische Maßnahmen 1. Prozessdesign a) Allgemein b) Sinn und Zweck c) Erstellung von TOMs d) Risikobewertung 2. Dokumentation 3. Technische Anpassung 4. Change 5. Vertrag
15 VIII. Archivierung und Löschung 1. Prozessdesign a) Archivierungs- & Löschkonzept b) Backup-System c) Organisatorisches Umsetzungskonzept d) Unstrukturierte Daten 2. Dokumentation 3. Technische Anpassung 4. Change 5. Vertrag
16 IX. Dienstleistermanagement 1. Prozessdesign a) Sinn und Zweck b) Risiken erweiterter Wertschöpfungskette c) Welche Maßnahmen? d) Initiale Dienstleisterauswahl e) Vertragserstellungsprozess f) Dienstleisterüberwachung g) Synergieeffekte mit anderen Bereichen 2. Dokumentation 3. Technische Anpassung 4. Change 5. Vertrag
17 X. Data Analytics, Big Data & KI 1. Prozessdesign a) Hintergrund b) Begriffsverständnis c) Regulatorik und Datenschutz d) Beispiel 2. Dokumentation 3. Technische Anpassung 4. Change 5. Vertrag
18 XI. Data Governance
19 XII. Operationelles Risiko
20 XIII. Einsatz eines Tools
21 XIV. Anhang 1. § 64 BDSG-neu 2. TOMs
Abkürzungsverzeichnis
| 3LoDM | three Lines of Defense Model |
| Abs. | Absatz |
| AO | Abgabenordnung |
| API | Programmierschnittstelle (Application Programming Interface) |
| Art. | Artikel |
| BaFIN | Bundesanstalt für Finanzdienst-leistungsaufsicht |
| BAIT | Bankaufsichtliche Anforderungen an die IT |
| BayLDA | Bayerische Landesamt für Datenschutzaufsicht |
| BDSG | Bundesdatenschutzgesetz |
| BITKOM | Bundesverband Informationswirtschaft, Telekommunikation und neue Medien |
| BSI | Bundesamt für Sicherheit in der Informationstechnik |
| BSIG | Gesetz über das Bundesamt für Sicherheit in der Informationstechnik |
| BSIG-KritisV | Verordnung zur Bestimmung Kritischer Infrastrukturen nach dem Gesetz über das Bundesamt für Sicherheit in der Informationstechnik |
| CNIL | Commission Nationale de l’Informatique et des Libertés |
| COBIT | Control Objectives for Information and Related Technology |
| DL | externer Dienstleister |
| DLP | Data Loss Prevention |
| DoS | Denial of Service |
| DS | Datenschutz |
| DSB | Datenschutzbeauftragter |
| DSFA | Datenschutz-Folgeabschätzung |
| DSGVO | Datenschutzgrundverordnung |
| DSK | Konferenz der unabhängigen Datenschutzbehörden des Bundes und der Länder |
| etc. | et cetera |
| EU | Europäische Union |
| ggf. | gegebenenfalls |
| GRC | Governance, Risk and Compliance |
| HGB | Handelsgesetzbuch |
| i.d.R. | in der Regel |
| i.V.m. | in Verbindung mit |
| ID | Identifizierung |
| IDS | Intrusion Detection System |
| IDW PS | Prüfstandard des Institut der Wirtschaftsprüfer |
| IDW RS FAIT | Stellungnahmen des Institut der Wirtschaftsprüfer zur Rechnungslegung vom Fachausschuss für Informationstechnologie |
| ISB | Informationssicherheitsbeauftragter |
| ISMS | Informationssicherheitsmanagement |
| ISO | Internationale Organisation für Normung |
| IT | Informationstechnologie |
| ITIL | IT-Infrastructure Library |
| ITSM | IT Service Management |
| KI | Künstliche Intelligenz |
| KWG | Kreditwesengesetz |
| LoD | Lines of Defense |
| MaRisk | Mindestanforderungen an das Risikomanagement |
| MS | Microsoft |
| o.ä. | oder ähnliches |
| OpRisk | Operationelle Risiken |
| PC | Personal Computer |
| PLZ | Postleitzahl |
| RACI | Responsible, Accountable, Consulted and Informed |
| SIEM | Security Information and Event Management |
| TOM | Target Operating Model |
| u.a. | unter anderem |
| USB | Universal Serial Bus |
| VAIT | Versicherungsaufsichtliche Anforderungen an die IT |
| vgl. | vergleiche |
| VL | Verteidigungslinie (im Sinne des Modells der 3 Verteidigungslinien) |
| VVT | Verzeichnis der Verarbeitungstätitgkeiten |
| z.B. | zum Beispiel |
| ZAG | Zahlungsdiensteaufsichtsgesetz |
Abbildungsverzeichnis
| Abbildung 1: | Strukturelle Ziele der DSGVO | 1 |
| Abbildung 2: | Datenschutzregulierungen | 2 |
| Abbildung 3: | Organisationspflichten eines klassischen Implementierungsprojektes | 5 |
| Abbildung 4: | Modell der drei Verteidigungslinien | 6 |
| Abbildung 5: | Dokumentenhierarchie eines Unternehmens | 8 |
| Abbildung 6: | Datenschutzmanagement eines klassischen Implementierungsprojektes | 11 |
| Abbildung 7: | Konvergenzen von Compliance Management Systemen, Datenschutzverwaltungsprogrammen und Informationssicherheitsmanagementsystemen | 13 |
| Abbildung 8: | Verarbeitungsverzeichnis eines klassischen Implementierungsprojektes | 25 |
| Abbildung 9: | Dimensionen des Datenaustausches | 26 |
| Abbildung 10: | Modellierung eines Verarbeitungsverzeichnisses auf Abteilungsebene | 27 |
| Abbildung 11: | Beispielhafte Aufteilung der Personalabteilung auf Prozessebenen | 28 |
| Abbildung 12: | Beispielhafte Aufteilung der Personalabteilung auf Verarbeitungsverzeichnislevel 3 | 29 |
| Abbildung 13: | Beispielhafte Aufteilung der Personalabteilung auf Verarbeitungsverzeichnislevel 3 | 44 |
| Abbildung 14: | Betroffenenrechte eines klassischen Implementierungsprojektes | 45 |
| Abbildung 15: | Prozessbearbeitung einer Betroffenenrechtsanfrage auf Level 2 | 52 |
| Abbildung 16: | Incident Management eines klassischen Implementierungsprojektes | 53 |
| Abbildung 17: | Phasenaufteilung des Incident Management | 55 |
| Abbildung 18: | Datenschutzrechtliche Bewertung von Incidents anhand einer Risikomatrix | 59 |
| Abbildung 19: | Implementierungsstrahl von TOMs | 64 |
| Abbildung 20: | Sicherheitslevel von datenschutzrechtlichen TOMs | 66 |
| Abbildung 21: | Archivierung und Löschung eines klassischen Implementierungsprojektes | 69 |
| Abbildung 22: | Beispiel für ein fachliches Archivierungskonzept | 74 |
| Abbildung 23: | Dienstleistermanagement eines klassischen Implementierungsprojektes | 79 |
| Abbildung 24: | Datenschutzrechtlicher Verantwortungsbereich | 80 |
| Abbildung 25: | Dienstleisterprüfung und -auswahl | 82 |
| Abbildung 26: | Implementierungsstrahl Data Analytics, Big Data & KI | 92 |
| Abbildung 27: | Zentrale Datenplattform, -haltung und -erhebung wegbegleitend zur Data Governance & Compliance | 94 |
| Abbildung 28: | Prozessdarstellung eines möglichen Betriebskonzeptes | 99 |
Tabellenverzeichnis
| Tabelle 1: | Prozessbearbeitung einer Betroffenenrechtsanfrage | 52 |
| Tabelle 2: | Beispielhafte Unterteilung von Prüfungshandlungen | 88 |
I. Methodik und Aufbau
1. Ausgangslage der DSGVO
„Fehlender Anleitungscharakter und zu geringer Detaillierungsgrad“ waren häufig diskutierte Kritikpunkte an der DSGVO. Beide Faktoren begünstigen Rechtsunsicherheit bezüglich der vorzunehmenden Maßnahmen.
Verordnungen wollen jedoch keine in Reinform anwendbare Checkliste bzw. Roadmap sein. Sie können i.d.R. auch nicht detaillierter gestaltet sein, da eine höhere Ausdetaillierung die erforderliche Flexibilität nach Art, Größe, Risiken etc. der Unternehmen nicht hinreichend ermöglichen würde.
Regulierungen formulieren i.d.R. Motivationen, Ziele und erzeugen damit Organisationspflichten. In Bezug auf die DSGVO können diese wie folgt strukturiert werden:

Abbildung 1: Strukturelle Ziele der DSGVO
Regulatorische Organisationspflichten werden i.d.R. mit Verwaltungsanweisungen oder Papieren der Aufsicht und aufsichtsnahen Gremien weiter interpretiert.
Abbildung 2: Datenschutzregulierungen
Auch dieser Detaillierungsgrad ist für die Arbeitspraxis meist noch nicht ausreichend. Die Erstellung von praktischen auf den konkreten Anwendungsfall operationalisierten Organisationsmodellen ist erforderlich. Funktionierende Lösungen sollten insbesondere folgende Anforderungen erfüllen:
•Berücksichtigung der Denk- und Organisationsstrukturen des Unternehmens
•Berücksichtigung der Arbeitskultur und der Prozessdisziplin
•Befähigung relevanter Akteure zur Durchführung der ihnen auferlegten Maßnahmen.
2. Operationalisierung
Jeder Beitrag zu den Organisationspflichten ist wichtiger Bestandteil zur Plausibilisierung der Funktionsfähigkeit des Organisationsmodells.
In Bezug auf die Erlangung von höchstmöglicher „Rechtssicherheit“ kann gelten: Die aus der DSGVO erwachsenden Organisationspflichten sind desto mehr erfüllt, je mehr der Geist der Regelung durch das gewählte Organisationsmodell erreicht wird und das gewählte Organisationsmodell dies nach außen hin auch ausreichend manifestiert.
In Anwendung der 80 % zu 20 % Regel bedeutet dies: 20 % des Arbeitsaufwandes müssen in Nachvollziehbarkeit der Arbeit investiert werden.
Die Organisationspflichten sind nach außen hin dann ausreichend manifestiert, wenn sie
•für einen sachkundigen Dritten
•nachvollziehbar und
•plausibel erscheinen
•und im Rahmen eines erfolgreichen Funktionstests verprobt wurden.
Proof of Concept: Bei IT-Projekten sind erfolgreiche Systemtests (u.a. User Acceptance Test) ganz selbstverständlich Voraussetzung für die „Live-Schaltung“ (z.B. für Banken geregelt in den MaRisk AT 7.2 Ziffer 3). Von einem erfolgreichen Arbeitsergebnis aus gedacht ist dies auch in der Prozess- und Dokumentationswelt sinnvoll.
• Nicht alle Organisationspflichten ergeben sich aus den hoheitlichen Vorgaben. Vom Ergebnis aus betrachtet können somit Maßnahmen erforderlich sein, die nicht explizit in der Regulierung enthalten sind. Das ist dann der Fall, wenn ausgehend von einem sinnvollen Arbeitsergebnis bestimmte notwendige Zwischenziele erreicht werden müssen. Beispiel hierfür ist ein „Vertragsmanagement“. Ein solches wird weder in der DSGVO (und im Übrigen auch nicht in der Finanzregulierung beim Outsourcing) explizit verlangt. Allerdings ist ohne ein vernünftig gestaltetes Vertragsmanagement eine ausreichende Dienstleistersteuerung nicht möglich. Das Vertragsmanagement ist somit eine Anforderung, die sich in diesem Fall aus dem Rückschluss der eigentlichen Zielerreichung ergibt. Die genaue Ausprägung des Vertragsmanagements liegt dabei im unternehmerischen Ermessensspielraum. Unter Berücksichtigung bestehender Strukturen und Arbeitskultur können mit diesem Ansatz im Ergebnis die passenden Arbeitsmodelle für das Unternehmen gewählt werden.
Organisationsmodelle sollten so plausibel gestaltet sein, dass eventuelle Diskussionen mit Aufsichtsbehörden nicht mehr grundsätzlicher Natur sind.
3. Aufbau der Kapitel
Die Organisationspflichten lassen sich wie folgt im Verlauf eines klassischen Implementierungsprojektes darstellen.
• Prozessdesign: Als Startpunkt soll ein gangbarer (Ablauf-) Prozess zur Erreichung der Ziele skizziert werden. Das Prozessdesign muss die Zielerreichung einer Maßnahme ausreichend plausibilisieren.
• Dokumentation: Im Arbeitsschritt Dokumentation müssen geeignete Dokumentationsformate erwogen und erzeugt werden. Diese bilden insbesondere Hilfestellung für den operativen Betrieb. Dazu zählen:○Arbeitsanweisungen,○ Handbücher,○ Mustervorlagen,○ Checklisten und sonstige Hilfsdokumente.Die Dokumentenart wird dabei in die Hierarchieebene einer üblicherweise bestehenden schriftlich fixierten Ordnung eingeordnet. Dies ist die im nachfolgenden Themenpunkt „Papershield“ noch näher erläuterte Dokumentenhierarchie.
• Technische Anpassung: In der Kategorie „IT“ ist zu prüfen, inwieweit für die Maßnahme eine technische Anpassung erforderlich ist und inwieweit eine technisch gestützte Lösung sachdienlich erscheint.
• Change-Management: In der Kategorie „Change“ ist zu prüfen, in welcher Form die neu geschaffenen Maßnahmen bzw. die erfolgte Umstrukturierung in geeigneter Weise in der Organisation „zum Leben erweckt“ werden können. Dazu gehören u.a. Schulungs- und Sensibilisierungsmaßnahmen sowie Kampagnen.
• Vertrag: Am Ende des Implementierungsstrahles ist zu prüfen, inwieweit Vertragsanpassungen erforderlich sind. Im Rahmen dieser Bearbeitung liegt der Schwerpunkt auf den „Back-End“-Verträgen mit Dienstleistern und Kooperationspartnern (und nicht auf dem „Front-End“ mit Kunden). In der Regel werden auf dieser Basis vorhandene Vertragstemplates oder Prüflisten für Vertragsverhandlungen aktualisiert.
• Proof of Concept: Es sollte erwogen werden, am Ende der Implementierungsmaßnahmen noch einen Testlauf zu ergänzen.

Abbildung 3: Organisationspflichten eines klassischen Implementierungsprojektes
4. Das Modell der “Three Lines of Defense”
Eine bewährte Herangehensweise zur Steuerung des Risikomanagements ist das Modell der „Three Lines of Defense“ (3LoD) oder das „Modell der drei Verteidigungslinien“.
Im Finanzsektor nimmt die BaFin in ihren Publikationen mittlerweile regelmäßig Bezug auf dieses Modell und „adelt“ diese Methodik damit in gewisser Weise zu einem gängigen und anerkannten Organisationsmodell im Finanzsektor. (So zum Beispiel in den „BaFin Perspektiven“ vom 01.08.2018 „Digitalisierung und Informationssicherheit im Finanz- und Versicherungswesen im Fokus aufsichtlicher Anforderungen“ abrufbar unter https://www.bafin.de/SharedDocs/Veroeffentlichungen/DE/BaFinPerspektiven/2018/bp_18-1_Beitrag_Gampe.html; abgerufen am 15.05.2019)
a) Modell der drei Verteidigungslinien

Abbildung 4: Modell der drei Verteidigungslinien
Das Modell gliedert sich in drei interagierende Verteidigungslinien mit folgendem Aufbau:
• Erste Verteidigungslinie: Die erste Verteidigungslinie bilden die operativ tätigen Fachbereiche. Sie sind für die Wirkung des Fachbereichs verantwortlich. Das umfasst die im Fachbereich erzeugten Arbeitsergebnisse – aber auch die aus der Fachbereichsarbeit resultierenden Risiken mit den damit korrespondierenden Kontrollen. Daher sind Fachbereiche insoweit für das Risikomanagement (Steuerung, Überwachung und Reduktion von Risiken) gegenüber der Geschäftsführung verantwortlich.
• Zweite Verteidigungslinie: Die zweite Verteidigungslinie ist für die Steuerung und Überwachung der Fachbereiche (also der ersten Verteidigungslinie) zuständig. Sie ist standardgebende Instanz und wacht über die Einhaltung der gesetzten Vorgaben. Entsprechend müssen die von der zweiten Verteidigungslinie erlassenen Vorgaben verständlich und umsetzbar sein.
• Dritte Verteidigungslinie: Die dritte Verteidigungslinie ist eine unabhängige Prüfungsinstanz (i.d.R. die Interne Revision) und prüft die Zuständigkeitserfüllungen der ersten und zweiten Verteidigungslinie. Die dritte Verteidigungslinie ist Ausprägung der Kontrollpflichten der Geschäftsleitung. Um der Geschäftsleitung die Unternehmenssteuerung auf Basis der Kontrollmaßnahmen zu ermöglichen, berichtet die dritte Verteidigungslinie direkt an die Geschäftsleitung.
Klassische Diskussionspunkte in Bezug auf die Arbeit der 2. Verteidigungslinie sind zu abstrakte und komplizierte Vorgaben. Nochmals wird daher hier der „Proof of Concept“ nahegelegt. Sind Vorgaben für den Fachbereich nicht verständlich oder umsetzbar, müssen diese nachjustiert werden.
b) „Außendatenschutz“ und „Papershield“
aa) Allgemein
Im Zuge des bevorstehenden Aktivierungstermines der DSGVO im Jahr 2018 kamen verstärkt die Begriffe „Außendatenschutz“ und im englischsprachigen Raum auch der Begriff „Papershield“ auf. Was verbirgt sich dahinter?
„Außendatenschutz“ ist das schwerpunktmäßige Bearbeiten der Themen mit „Außenweltberührung“. Hierzu zählen beispielsweise die Datenschutzbelehrungen im Web-Auftritt, datenschutzkonforme Vertragsklauseln etc.
Papershield ist insbesondere der Arbeitsansatz im englischsprachigen Raum, alle notwendige Dokumentation für eine regelkonforme Organisation zu schaffen. Dieser Gedanke ist in einem ersten Schritt zunächst zielführend. Allerdings müssen in einem weiteren Schritt die Inhalte in der Organisation auch tatsächlich zum Leben erweckt werden.
Die Bankenregulierung hat in MaRisk AT 5 und AT 6 die Dokumentationsanforderungen explizit formuliert. Diese können für andere Bereiche Inspiration sein.
Welche Dokumentationsanforderungen sind aus der DSGVO ableitbar?

Abbildung 5: Dokumentenhierarchie eines Unternehmens
bb) Dokumentenstruktur
Die vorhandene Dokumentenstruktur eines Unternehmens kann im Rahmen einer Dokumentenhierarchie in vier Hierarchieebenen gegliedert werden:
Im Einzelnen:
Zu Level 1: Übergeordnete Leit- und Richtlinien mit grundsätzlicher Themenbehandlung. Hierzu gehören Richtlinien zum Thema Datenschutz, die auf der entsprechenden „Flughöhe“ datenschutzrechtliche Themen aufgreifen und behandeln.
Zu Level 2: Hierzu gehören Bestandteile eines bereits spezielleren Themas, die eine vollumfängliche eigene Darstellung erfordern. Z.B. das Thema Archivierung und Löschung, Berechtigungsmanagement etc.
Zu Level 3: Nach altem datenschutzrechtlichen Verständnis erschöpfte sich die Dokumentation häufig bereits in den zuvor dargestellten Level 1 und 2.
Hieraus resultierte das flächendeckend verbreitete Phänomen, dass die datenschutzrechtlichen Vorgabendokumente durch die Fachbereiche bei deren Tagesarbeit nicht berücksichtigt wurden, weil sie schlichtweg nicht bekannt waren.
Teils wurde nur eine datenschutzrechtliche Leitlinie/Richtlinie erstellt, die unter Umständen nicht einmal ausreichend im Unternehmen kommuniziert wurde.
Fachbereiche arbeiten in erster Linie mit den für die jeweilige Fachbereichsarbeit erstellten Arbeitsanweisungen. Es hat sich bewährt, fachbereichsfremde Themen als Merkpunkte, Verlinkungen oder Kurzkapitel in das fachbereichsspezifische Dokument hineinzutragen und einzuarbeiten. Der Bearbeiter eines Themas wird auf diesem Wege mit einer zu beachtenden datenschutzrechtlichen Maßnahme unausweichlich konfrontiert.
Zu Level 4: Hilfsdokumente zur Unterstützung der themenspezifischen Vorgaben sind z.B. in Form einer Matrix, Vorlage/Template oder Checkliste erstellt.
Beispiel: Ein Beispiel ist das Verarbeitungsverzeichnis.
Im Level 1 Dokument (für den Bereich Datenschutz die Datenschutzrichtlinie) wird definiert, dass ein Verarbeitungsverzeichnis zu führen ist. Es werden auch die Grundsätze festgelegt. Bei dem Thema „Verarbeitungsverzeichnis“ besteht ein umfassender Erläuterungsbedarf (auf welchem Detaillevel ist es zu führen, welche Akteure sollen es führen, welche sind die Aktualisierungsereignisse etc.).
Daher empfiehlt sich die Anfertigung einer eigenen Arbeitsanweisung für dieses Thema (also ein Level 2 Dokument). Das Verarbeitungsverzeichnis ist i.d.R. dann zu aktualisieren, wenn neue Prozesse im Unternehmen geschaffen oder bestehende Prozesse abgeändert werden. In diesen im Schwerpunkt auf Organisationsänderung angelegten Prozessen sollte die Aktualisierung des Verarbeitungsverzeichnisses als Merkposten mit aufgenommen werden. Das kann z.B. ein zusätzlicher Prüfpunkt bei einem Projektsteckbrief oder ein zusätzlicher Prüfpunkt einer Checkliste für den Einkauf von Dienstleistungen sein. Hierbei handelt es sich nach dieser Nomenklatur um eine „Level 3“ Dokumentation.
Für das Verarbeitungsverzeichnis wird idealerweise eine Vorlage erstellt (etwa auf MS Excel Basis). Ebenfalls wird möglicherweise noch ein eher pragmatisch und einfach gestalteter Ausfüllhinweis erarbeitet. Bei beiden Dokumenten würde es sich nach dieser Nomenklatur um ein Level 4 Dokument handeln.
II. Datenschutzmanagement
1. Prozessdesign
a) Datenschutzmanagementsystem
Der Begriff „Managementsystem“ kann wie folgt definiert werden:
Managementsysteme können als ein systematisches, gezieltes und geplantes Herangehen an die Umsetzung der Unternehmenspolitik und von Unternehmenszielen bezeichnet werden. Dies geschieht, indem die Managementsysteme die betrieblichen Prozesse steuern, eine Prozess strukturierung in die Wege leiten und die im Unternehmen bestehenden Abläufe und Prozesse optimieren. 1

Abbildung 6: Datenschutzmanagement eines klassischen Implementierungsprojektes
In der Informationssicherheit wird nahezu nur noch in dieser Denkweise gearbeitet (Informationssicherheitsmanagementsystem). Das BSI spricht in dem IT lastigen Datenschutzbaustein M 2.501 von „Datenschutzmanagement“ (Quelle abgerufen am 2. Juni 2019: https://www.bsi.bund.de/DE/Themen/ITGrundschutz/ITGrundschutzKataloge/Inhalt/_content/m/m02/m02501.html
Managementsysteme behandeln Themenkomplexe aus dem Blickwinkel des gesamtheitlichen „Orchestrierens“ und unter Berücksichtigung des „Lifecycles“.
Der Aspekt des „Lifecycles“ kommt mit dem Demingkreis2 (Plan, Do, Check, Act) besonders gut zum Ausdruck.
Der „Orchestrierungsgedanke“ für Compliance-Themen wie Datenschutz kann hingegen aus dem Standard des Instituts der Deutschen Wirtschaftsprüfer IDW PS 980 interpretiert werden.3 Ein Compliance Managementsystem besteht demnach aus
○ Compliance-Kultur
○ Compliance-Zielen
○ Compliance-Risiken
○ Compliance-Programm
○ Compliance-Organisation
○ Compliance-Kommunikation
○ Compliance-Überwachung
Ist die Compliance-Organisation in einem Unternehmen nach diesem Standard ausgerichtet, so kann es sinnvoll sein, auch die datenschutzrechtliche Organisation nach diesem Standard auszurichten.4
Mit dem IDW PS 9.860.1 gibt es mittlerweile auch einen eigenen Prüfungsstandard der Wirtschaftsprüfer für Datenschutz. Allerdings eignet sich auch dieser weniger als Organisationsgerüst, da dieser schwerpunktmäßig aus dem Blickwinkel einer Prüfung verfasst ist.
Es gibt jedoch eine Vielzahl weiterer passender Standards, die als Organisationsgerüst genutzt werden können. Hat sich z.B. ein Unternehmen nach COBIT 5 ausgerichtet (Framework zur IT-Governance) – so lohnt sich die Prüfung, inwieweit diese Strukturen für den Datenschutz (mit)genutzt werden können.
Dies gilt auch für andere Strukturen, die im Unternehmen bereits bestehen und ggf. umgewidmet werden können.
Abbildung 7: Konvergenzen von Compliance Management Systemen, Datenschutzverwaltungsprogrammen und Informationssicherheitsmanagementsystemen
Besteht die Wahl, so erscheinen aus Sicht eines operativ ausgerichteten Datenschutzmanagements jedoch andere Strukturierungsmodelle für den Datenschutz passender.
b) Datenschutzkonzept
Das Datenschutzkonzept ist der planerische Bestandteil des Datenschutzmanagements. Aus dem Datenschutzkonzept sollte sich das Organisationsmodell für den Betrieb des Datenschutzmanagements ergeben.
Als Einstieg für ein Datenschutzkonzept bietet sich initial eine umfassende Gap-Analyse der Datenschutzorganisation an. Diese sollte alle Fragen aufwerfen, die sich unter Berücksichtigung des Geschäftsmodells und der konkreten Bedürfnisse hinsichtlich des Datenschutzes an das jeweilige Unternehmen ergeben.
c) Aufgaben, Rollen & Verantwortlichkeiten
aa) Allgemein
Die Klärung personeller und finanzieller Ressourcen wird meist hintenangestellt und somit auf das Ende einer Projektmaßnahme verlegt. Rollen und Verantwortlichkeiten der Ziellösung haben aber in der Regel erheblichen Einfluss auf die Gestaltung der Arbeitsorganisation.
Daher sind Rollen und Verantwortlichkeiten im Idealfall bei Beginn einer Umstrukturierung zu definieren. Ansonsten kann weder die Arbeitsorganisation noch das Arbeitsmaterial zielgruppengerecht ausgestaltet werden.
bb) Welche Aufgabenverteilung besteht?
Oftmals haben die involvierten Akteure eine unterschiedliche Sichtweise auf das Thema „Datenschutz im Unternehmen“. Zur Verdeutlichung soll ein Auszug der Stimmen der relevanten Akteure aus dem Bereich Geschäftsleitung, Fachbereich und Datenschutz widergegeben werden:
Stimmen aus dem Fachbereich:
• Datenschutz, macht bei uns der Datenschützer.
• Allein der Datenschutz hat dafür Sorge zu tragen, dass wir datenschutzrechtlich sauber sind.
• Ich verstehe nicht, was aus datenschutzrechtlicher Sicht zu tun ist. Klare Leitlinien sind für mich nicht greifbar. Der Bereich Datenschutz kann uns auch kein geeignetes Material zur Verfügung stellen.
• Datenschutz macht doch die IT?
Stimmen aus dem Bereich Datenschutz:
• Die Abteilung Datenschutz hat nur beratende und prüfende Funktion.
• Der Bereich Datenschutz hat nicht genügend Ressourcen.
• Die Geschäftsführung ist die verantwortliche Stelle. Sie ist somit auch für das Datenschutzmanagement verantwortlich.
• Die Fachbereiche sind für den operativen Datenschutz verantwortlich.
• Der Fachbereich muss das für ihn relevante datenschutzrechtliche Material selbst erstellen und dem Bereich Datenschutz zur Prüfung vorlegen.
Stimmen der Geschäftsleitung:
• Ich kann den Mehrwert von Datenschutz noch immer nicht erkennen.
• Datenschutz bremst nur die Geschäftsentwicklung.
• Die DSGVO war nur ein Sturm im Wasserglas. Bedrohliche Strafen werden weiterhin nicht verhängt. Entsprechend widme ich mich wichtigeren Themen.
Diese Stimmen zeigen den häufig initialen Klärungsbedarf im Bereich Sinn und Zweck, Aufgaben sowie Rollen und Verantwortlichkeiten. Damit sind insbesondere folgende Fragen zu klären:
• Wer betreibt operativ das Datenschutzmanagement?
• Welche datenschutzrechtlichen Aufgaben haben jeweils die Akteure Geschäftsleitung, Fachbereich und Datenschutzbeauftragter?
• Welche Verantwortung (und welche Haftung) haben die Akteure Geschäftsleitung, Fachbereich und Datenschutzbeauftragter?
• Welche Dokumentation ist von welchem Akteur zu erstellen?
• Inwieweit muss ein Akteur den anderen zu dessen Aufgaben befähigen?
Der Themenpunkt der Aufgabenverteilung benötigt besondere Beachtung, weil Art. 38 DSGVO und Art. 39 DSGVO insbesondere die beratende und prüfende Funktion des Datenschutzbeauftragten beinhalten. Weitere Organisationspflichten ergeben sich hieraus nicht. Die Datenschutzkonferenz schreibt mit dem Kurzpapier Nr. 12:
„Verantwortung für die Einhaltung der DS-GVO
Die DS-GVO stellt in Art. 24 Abs. 1 DS-GVO ausdrücklich klar, dass es die Pflicht des Verantwortlichen bzw. des Auftragsverarbeiters – und nicht des DSB – bleibt, sicherzustellen und nachzuweisen, dass die Datenverarbeitungen im Einklang mit den Regelungen der DS-GVO stehen. Gleichwohl sollte der DSB seine Tätigkeiten in angemessener Weise dokumentieren, um ggf. nachweisen zu können, dass er seinen Aufgaben (insbesondere Unterrichtung und Beratung) ordnungsgemäß nachgekommen ist.“
Liest man Gesetz und Kurzpapier, kann der Eindruck entstehen, dass der Datenschutzbeauftragte nur prüfende und beratende Funktion hat und nicht auch für den Betrieb des Datenschutzmanagements zuständig ist. Dann drängt sich aber die Frage auf, wer das Datenschutzmanagement denn eigentlich betreibt.
• Die Geschäftsführung ist ausweislich Art. 24 DSGVO die „Verantwortliche Stelle“. Sie kann aber hinsichtlich des Datenschutzmanagements nicht handelnder Akteur sein. Die Geschäftsleitung ist kein operativ agierender Akteur. Die Geschäftsleitung trägt die Verantwortung und nimmt strategische und kontrollierende Aufgaben wahr (ggf. nach Vorstandsressourcen unterteilt). In den entsprechenden Kompetenzlinien werden die Aufgaben auf hierarchisch nachrangig gelagerte Abteilungen delegiert.
• Die operativen Fachbereiche (also aus Datenschutzsicht die Fachbereiche der 1. Verteidigungslinie) können ebenfalls kein übergreifendes Datenschutzmanagement betreiben. Als Teilverantwortliche des fachbereichsspezifischen Datenschutzmanagements ist für die Fachbereiche im Schwerpunkt der eigene Beitrag relevant.
• Es müsste also ein zusätzlicher zweiter Fachbereich Datenschutz eigens für den Betrieb des Datenschutzmanagements geschaffen werden. Darin würde aber in stringenter Fortführung der skizzierten Aufgaben von Prüfung und Beratung der DSB keine Funktion haben. Das würde zu dem Ergebnis führen, dass der höchste datenschutzrechtliche Knowhow-Träger im Unternehmen quasi im „Maschinenraum“ des Datenschutzes – nämlich dem Datenschutzmanagement – keine Aufgabe inne hat.
Auch in einigen Unterlagen zur Durchführung eines DSGVO Projektes war zu lesen, dass der DSB keine gestalterische Funktion einnehmen soll. Das war gleich aus 2 Gründen optimierbar:
• Das wichtige Know-How des DSB fehlt in diesen Fällen.
• Die DSB versäumen ihre „historische“ Chance, die eigene Arbeitswelt nach ihren Vorstellungen maßgeblich mitzugestalten.
In der Praxis hat sich diese Herangehensweise als nicht erfolgreich erwiesen. Fachfremd besetzte DSGVO Projekte wirkten fachlich immer überfordert. Auch die fachfremde Besetzung des Linienbetriebes war nie ein Erfolgsmodell.
cc) Lösung durch Anwendung des 3LoDM
Die Anwendung des Modells der „3 Verteidigungslinien“ führt übertragen auf den Datenschutz zu folgendem Ergebnis:
Die erste Verteidigungslinie (VL) bilden die operativ tätigen Fachbereiche bei der Verarbeitung personenbezogener Daten im Rahmen ihrer Fachbereichsarbeit. Übertragen auf den Datenschutz sind die Fachbereiche für die unmittelbare Beachtung und Umsetzung der Anforderungen des Datenschutzes im operativen Geschäftsbetrieb des jeweiligen Fachbereichs zuständig. Das ist insofern sachgerecht, weil die Fachbereiche die fachbereichsspezifischen Risiken meist am besten einschätzen können und die Fachbereichsarbeit das datenschutzrechtliche Risiko i.d.R. auch überwiegend einfärbt. Graubereiche sind über die genaue Aufteilung von Aufgaben und Verantwortlichkeiten im Datenschutzmanagement unter dem Thema „Rollen und Verantwortlichkeiten“ abzustecken.
Die zweite Verteidigungslinie besteht aus dem Datenschutzbeauftragten bzw. dem Fachbereich Datenschutz mit den folgenden Aufgaben:
• Aufbau und Betrieb des Datenschutzmanagements. Das Datenschutzmanagement muss die Aufbau- und Ablauforganisation und die schriftlich fixierte Ordnung der jeweiligen Organisation berücksichtigen.
• Datenschutzrechtliche Vorgaben müssen in Form von Standards für die Organisation in die schriftlich fixierte Ordnung überführt werden.
• Verbesserung und Weiterentwicklung des Datenschutzmanagements (Im Sinne des Deming-Kreises).
• Ferner hat die zweite Verteidigungslinie folgende Aufgaben:○ Überwachungsfunktion des Datenschutzes○ Beratungsfunktion zu Fragen des Datenschutzes
Die dritte Verteidigungslinie ist auch im Fall des Datenschutzes die Interne Revision. Diese muss die Umsetzung des Datenschutzes regelmäßig auf Angemessenheit und Wirksamkeit hin überprüfen. Für die Interne Revision gelten dabei die allgemeinen Prüfungspflichten. Weitergehende spezifische Prüfungspflichten – insbesondere aufgrund spezieller gesetzlicher Anforderungen – bestehen allerdings nicht. Daher wird die Arbeit der Internen Revision in dieser Handreichung auch nicht weiter konkretisiert.
Datenschutzkoordinatoren: Eine gute Lösung ist die Benennung von Datenschutzkoordinatoren. Die dezentrale Ansiedlung der Koordinatoren ermöglicht eine breite fachliche Abdeckung des Themas.
Diese sind in der 1. VL angesiedelt. Bei diesem Organisationsmodell wird in den Fachbereichen ein Hauptansprechpartner für Datenschutz geschaffen. Dieser wird mit den datenschutzrechtlichen Aufgaben betraut. Er ist dann sowohl Ansprechpartner für die Mitarbeiter des jeweiligen Fachbereiches zu allen Belangen des Datenschutzes, als auch Ansprechpartner für den Datenschutzbeauftragten/ Fachbereich Datenschutz. Dieses Arbeitsmodell ist bereits aus anderen regulatorischen Themen bekannt und bewährt.
Beim Thema Datenschutz ist noch immer das Thema „Personalknappheit“ Dauerthema. Die vorbenannte Erweiterung des Aufgabenspektrums müsste sich in den Ressourcen widerspiegeln.
Wurde nicht ohnehin in den DSGVO Projekten eine Personal-Bedarfsplanung durchgeführt, so kann diese nachgeholt werden. Aus aufsichtsrechtlicher Sicht müssen im Ergebnis auch die Ressourcen für die Erledigung der Aufgaben plausibel erscheinen.
d) Problemfelder bei Anwendung des 3LoDM
Die standardgebende Einheit Datenschutz trägt häufig vor, nicht zu operativ tätig werden zu dürfen (und zu müssen5) und ferner gar nicht die Ressourcenausstattung dafür zu haben.
Müssen also die Fachbereiche den Datenschutz in operativer Hinsicht maßgeblich organisieren und betreiben? Die Fachbereiche sind am Rande Anwender der datenschutzrechtlichen Vorgaben – so wie sie auch Anwender zahlreicher weiterer regulatorischer Vorgaben sind (z.B. Informationssicherheit, Geldwäsche etc.). Aufgrund der Vielfältigkeit der Compliance-Themen können bzw. sollen (unter dem Gesichtspunkt der Ressourcenschonung) Fachbereiche erst gar nicht tiefere Expertise in den für sie peripheren Themen aufbauen.
Als Faustformel kann gelten: je mehr die Fachbereiche mit für sie fachfremder Arbeit betraut werden, desto mehr benötigen sie operationalisierte und detaillierte Vorgaben, Hilfsmittel und Schulungen. Im „Proof of Concept“ können neu erstellte Strukturen und Maßnahmen vor der Überführung in die Linientätigkeit verprobt werden. Entsprechend müssen die Fachbereiche bei ihren datenschutzrechtlichen Tätigkeiten unterstützt werden.
Welcher Beitrag kann realistischer Weise von den Fachbereichen erwartet werden?
Welche Aufgaben müssen die Fachbereiche bei einer Gesamtbetrachtung sinnvollerweise noch durchführen?
Selbst die Befähigung hoch lernbereiter Fachbereiche hat ihre Grenzen. Eine richtig durchgeführte Datenschutzfolgenabschätzung zum Beispiel erfordert tieferes datenschutzrechtliches Wissen und Fertigkeiten in der Anwendung von Risikomanagementmethoden. Themen, die mit „Anlernmaßnahmen“ wie Kurzschulungen und der Lektüre von Hilfsmaterial aufgrund der Komplexität nicht durchdrungen werden können, sollten mit einem engen beraterischen Begleitprozess ausgestattet sein.
e) Verantwortung und Haftung
Die „schwierige“ Eingrenzung des Haftungs- und Wirkungsbereichs von Compliance-Funktionen hängt mit dem besonderen Spannungsfeld zusammen. Der Bereich Datenschutz soll nach Vorstellung des gesetzlichen Auftrages in erster Linie die Interessen der Betroffenen schützen. Aus Sicht des Unternehmens handelt es sich hierbei um „Fremdziele“, die mit Unternehmensinteressen kollidieren können.
Der zweite Grund hängt mit der besonderen Figur des gesetzlich vorgeschriebenen „Beauftragtenwesens“6 zusammen. Nach dem gesetzlichen Leitbild stellen „die Beauftragten“ den verlängerten Arm der Behörden dar. Entsprechend sind sie mit Schutzmechanismen (z.B. ausgeprägter Kündigungsschutz nach dem alten BDSG) ausgestattet. Die Aufsichtsorgane schützen „ihren Beauftragten“ vor Repressalien des Unternehmens. Aktuelle Instrumente sind z.B.:
• Die Geschäftsführung und nicht der Beauftragte ist verantwortlich.
• Der Datenschutzbeauftragte ist weisungsfrei.
Wie kann dieser Zielkonflikt in der Gemengelage des Datenschutzes interessengerecht aufgelöst werden?
Wir nähern uns diesem Problem im Folgenden wieder ausgehend von dem vorgeschlagenen Organisationsmodell der 3 LoD sowie einem sachgerechten Ergebnis, das alle Akteure und Beteiligten und die Unternehmensinteressen berücksichtigt. Eine geeignete Auflösung dieses Konfliktes kann durch die gedachte Trennung zwischen dem Team des Datenschutzbeauftragten (also den Fachbereich Datenschutz) und dem Datenschutzbeauftragten in seiner gesetzlich zugedachten Form gelingen. Die Rolle des Datenschutzbeauftragten ist dann letztendlich zweigeteilt. Zum einen handelt der DSB in seiner gesetzlich zugedachten Form (als Berater und Prüfer) und zum anderen ist er Teamleiter des Fachbereiches Datenschutz.
Denn auch für den Fachbereich Datenschutz bzw. für den Datenschutzbeauftragten gelten Loyalitätspflichten gegenüber dem Unternehmen. Diese sind durch den besonderen gesetzlichen Auftrag nicht gänzlich aufgehoben (was teils allerdings so diskutiert wird). Vielmehr treten diese nur insoweit zurück, wie sie der Wahrnehmung der gesetzlich übertragenen Aufgaben entgegenstehen. Entscheidend ist, dass weitere zugewiesene Aufgaben vor dem Hintergrund verfügbarer Kapazitäten wahrgenommen werden können und die Aufgaben nicht mit den gesetzlichen Aufgaben des jeweiligen Beauftragtenwesens kollidieren.
Auch das Arbeitsmodell der 3 LoD interpretiert die arbeitsrechtlichen Loyalitätspflichten der 2. VL dahingehend, optimale Rahmenbedingungen zur Einhaltung der datenschutzrechtlichen Vorgaben für das Unternehmen zu schaffen. Nur so ist das Unternehmen in der Lage, datenschutzrechtliche Expertise optimal zu nutzen. Nur dann ist der Datenschutz im Übrigen auch maximal effektiv. Der Datenschutzbeauftragte ist i.d.R. bzw. sollte höchster datenschutzrechtlicher Knowhow-Träger sein.
Die interne Verantwortung des Datenschutzbeauftragten für „sein“ Datenschutzmanagement kollidiert auch nicht mit der Weisungsfreiheit. Diese bezieht sich – wie auch in anderen Berufen mit ähnlichen Funktionsmodellen – in erster Linie auf die Inhalte von Entscheidungen. Unberührt davon bleibt, ob die Arbeit
• ordnungsgemäß organisiert ist
• und ein angemessenes Arbeitspensum erledigt wird.
Die Fachbereiche müssen die Vorgaben des Datenschutzbeauftragten und seines Teams (der 2. VL) auf die konkreten Anforderungen in ihrem Fachbereich anpassen und operationalisieren.
Fehlt Kapazität oder andere Ressourcen (wie etwa Tools) – so ist die Geschäftsleitung darüber (ggf. mit dem entsprechenden Nachdruck) zu informieren und mit entsprechenden Lösungsvorschlägen zu versorgen. Die Geschäftsleitung kann auf Basis dieses Vorschlages ihre Steuerungsfunktion wahrnehmen (z.B. durch Aufbau der Ressource). Belässt sie in Kenntnis der Tragweite die Situation und wird die Angelegenheit schlagend, so wird sie im Rahmen ihrer Verantwortung dafür die Konsequenzen tragen müssen.
Checkliste Rollen und Verantwortlichkeiten
1. Sind die Rollen und Verantwortlichkeiten ausreichend geklärt?
2. Sind die Aufgaben mit einer realistischen Erwartungshaltung verteilt?
3. Werden insbesondere die Fachbereiche ausreichend mit Hilfsmitteln wie Arbeitsanweisungen, Templates und Schulungen für ihre Arbeit befähigt?
4. Ist eine Aufwandsplanung für den Datenschutz erstellt? Wird der zusätzliche Aufwand berücksichtigt?
5. Sind die Rollen und Verantwortlichkeiten ausreichend an die betroffenen Personen kommuniziert?
Ücretsiz ön izlemeyi tamamladınız.