Buch lesen: «Datenschutz mit bewährten Methoden des Risikomanagements»

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.

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