Navigation
Seiteninhalt

Datenschutz: Das optimale „Privacy Impact Assessment“ nach der DSGVO

Die EU-Datenschutzgrundverordnung (DSGVO) wird am 25. Mai 2018 wirksam. Gemäß Artikel 35 der Verordnung ist eine Datenschutzfolgeabschätzung (DSFA) durchzuführen. Es fragt sich, wann und mit welchen Instrumentarien dies geschehen soll und vor allem, wie man die DSFA im Unternehmen implementieren kann, ohne den Arbeitsaufwand für die Fachabteilungen unverhältnismäßig zu erhöhen.
Von Christian Brockhausen MBA
01. September 2017 / Erschienen in Compliance Praxis 3/2017, S. 19

Problemstellung

Die Methode einer Datenschutzfolgeabschätzung (DSFA), auf Englisch Privacy Impact Assessment (PIA) genannt, ist im internationalen Vergleich nicht neu, stellt aber aktuell gerade Unternehmen, die bislang keine datenschutzrechtliche Risikoanalyse vorgenommen haben, vielfach vor prozessuale Herausforderungen. Es stellen sich häufig folgende Fragen:

  • Wann ist eine DSFA durchzuführen?

  • Mit welchen Mitteln kann sie durchgeführt werden?

  • Welche Möglichkeiten der technischen Umsetzung gibt es?

Merkmale einer DSFA

Eine Datenschutz-Folgenabschätzung

  • beschreibt die Verarbeitungstätigkeit von personenbezogenen Daten,

  • bewertet deren Notwendigkeit und Angemessenheit und

  • hilft, die Risiken für die Freiheiten und Rechte natürlicher Personen in den Griff zu bekommen.

Diese Risiken werden bewertet und es werden Maßnahmen zu deren Adressierung festgelegt, das heißt, die Eintrittswahrscheinlichkeit der erkannten Risiken zu minimieren. Die Risikoanalyse ist aufgrund objektiver Kriterien durchzuführen; es werden Faktoren wie Eintrittswahrscheinlichkeit, Schaden sowie Art, Umstände, Umfang und Zweck der Verarbeitung betrachtet.

Die Eintrittswahrscheinlichkeit richtet sich nach den Erwägungsgründen 90 und 91 der DSGVO und ist aus Sicht des Betroffenen zu beurteilen, wobei die „Risiko-Quelle“ (der Angreifer) zu identifizieren ist. Art 35 DSGVO beschreibt die Schritte hinsichtlich des Vorgehens bei einer DSFA (vgl Abbildung 1).

Abbildung 1: Grundsätzliches Vorgehen bei einer DSFA, © Brockhausen
Abbildung 1: Grundsätzliches Vorgehen bei einer DSFA

Somit ist das grundsätzliche Vorgehen das folgende:

1.  Es ist eine Risikoanalyse vorzunehmen.

2.  Wo aus der Analyse ein hohes Risiko resultiert, ist eine DSFA zu erstellen, in deren Rahmen auch die technischen, organisatorischen und rechtlichen Maßnahmen darzustellen sind, die dem Risiko bzw der Eintrittswahrscheinlichkeit entgegenwirken („Privacy Controls“). Diese Maßnahmen ergänzen die Datensicherheitsmaßnahmen (Art 32 DSGVO).

3.  Verbleibt auch nach Durchführung der festgelegten Maßnahmen noch immer („restlich“) ein „hohes Risiko“, dann ist die zuständige Aufsichtsbehörde zu konsultieren.

Die Risikoanalyse

Es stellt sich zunächst die Frage, wann ein Sachverhalt vorliegt, der datenschutzrechtlich als (hohes) Risiko einzustufen ist. Die DSGVO wird in ihrer Anwendung stets zusammen mit den entsprechenden Erwägungsgründen sowie den Hinweisen der Aufsicht anzuwenden sein. Zur Aufsicht gehören auch Stellungnahmen und Erwägungen der sogenannten Artikel-29-Gruppe. Der Name geht zurück auf Art 29 DSGVO. Die Gruppe stellt das unabhängige Beratungsgremium der Europäischen Kommission für Fragen des Datenschutzes dar.

Diese Gruppe veröffentlichte vor kurzem Kriterien für das Vorliegen eines datenschutzrechtlichen Risikos. Ein solches liegt demnach in folgenden Fällen vor:

  • Scoring, Profiling, Evaluation, zB Einschätzung der Kreditwürdigkeit, Behavioral Marketing etc,

  • automatisierte Einzelfallentscheidungen,

  • systematische Überwachung,

  • Verarbeitung sensibler Daten,

  • umfangreiche Datenverarbeitungen (bezogen auf die Anzahl betroffener Personen und Datenkategorien, die Dauer der Verarbeitung, die geographische Ausdehnung),

  • das Zusammenführen oder Abgleichen von Datenbeständen, wenn Betroffene nicht damit rechnen können,

  • die Verarbeitung von Daten besonders schutzbedürftiger Personen,

  • Neuartigkeit von Verarbeitungsvorgängen, Verwendung neuer Technologien (zB Fingerabdrucksensoren oder Gesichtserkennung),

  • Übermittlung von personenbezogenen Daten an Empfänger außerhalb der EU,

  • Verarbeitungen, die es betroffenen Personen erschweren, ihre Rechte auszuüben oder eine Leistung in Anspruch zu nehmen, zB die Beurteilung der Kreditwürdigkeit durch eine Bank vor der Vergabe eines Darlehens.

Als „Faustregel“ wurde beschrieben, dass bei Vorliegen von mindestens zwei dieser Kriterien ein Risiko vorliegt, das eine DSFA rechtfertigt.

Das Mittel für die DSFA

Es hat sich vielfach etabliert, eine derartige Risikoanalyse mit Hilfe eines sogenannten Privacy Impact Assessments (PIA) durchzuführen.

Was ist ein Privacy Impact Assessment (PIA)?

Ein Privacy Impact Assessment (PIA) ist eine systematische Analyse der Auswirkungen einer Anwendung auf Privatsphäre und Datenschutz. Eine PIA stellt somit eine Datenschutzfolge- und Risiko-Abschätzung dar. PIAs sind seit einigen Jahren im englischsprachigen Raum gebräuchlich. In der Regel handelt es sich um einen Fragebogen (Questionnaire), welcher Fragen enthält, aus deren Antworten sich die zuvor beschriebenen Risiken ableiten lassen, aber auch adressieren lassen, um entsprechende Gegenmaßnahmen einzuleiten.

Anwendungsbereich eines derartigen PIA sind die Applikationen, aber auch die Prozesse eines Unternehmens. Gerade aus den Letzteren lässt sich bei entsprechender Konzeption das in Art 30 DSGVO geforderte Verfahrensverzeichnis ableiten.

Inhalt des PIA

Wie zuvor beschrieben dient das PIA der Risikoanalyse. Diese kann nur unternehmensindividuell durchgeführt werden. Gleichwohl gibt es Sachverhalte, die ein PIA auf jeden Fall abfragen sollte: Es empfiehlt sich zunächst einmal abzufragen, ob das System oder der Prozess personenbezogene Daten verarbeitet. Hinzu kämen – nimmt man als Anhaltspunkt die Kriterien der Artikel-29-Gruppe – Fragen nach den jeweiligen Sachverhalten wie etwa Datenübertragung in Länder außerhalb der EU; Verwendung von Gesundheitsdaten usw. Denkbar wäre es, noch Fragen von grundsätzlichem Interesse einzufügen. Denkbar wäre hier der Punkt der Vertraulichkeitserklärungen.

Wie zuvor beschrieben ist immer der Geschäftszweck des Unternehmens bzw seine Kundenstruktur in die Überlegungen mit einzubeziehen.

Wer ist Adressat eines PIA?

Bei dieser Frage empfiehlt es sich, in der Vorbereitung eines PIA-Fragebogens erhöhte Aufmerksamkeit walten zu lassen. Führt man sich nämlich die jeweiligen Rollen eines Unternehmens vor Augen, so ist diese Frage nicht einfach zu beantworten.

Die lediglich für eine IT-Applikation verantwortliche Person wird bspw kaum beantworten können, ob ein System Gesundheitsdaten benutzt oder nicht.

Man benötigt demnach Adressaten aus den Fachbereichen, die tatsächlich mit der Applikation arbeiten. Je nach Rollenmodell des Unternehmens können dies sogenannte „Business Application Owner“ sein.

Bei der ersten Durchführung eines PIA empfiehlt es sich, genügend Zeit einzuplanen. In der Regel dürfte man im Zuge der Ermittlung des Adressaten auch auf ungeklärte Fragen im Rahmen des Rollen- und Berechtigungskonzeptes stoßen.

Anforderungen an ein PIA

Es stellt sich die Frage, welchen Anforderungen ein PIA genügen muss. Dies insbesondere im Hinblick auf den Adressaten. Es gilt nämlich, den Arbeitsaufwand für den Fachbereich so gering wie möglich zu halten. Dies erhöht nicht zuletzt auch das Bewusstsein für das Thema Datenschutz.

Grundsätzlich gilt das Folgende:

  • Durchführung des PIA sowohl für Applikationen als auch Prozesse;

  • Anwendung einer einfachen, auch vom datenschutzrechtlichen Laien zu verstehenden Sprache;

  • je nach Unternehmensausrichtung Mehrsprachigkeit;

  • so wenig wie möglich Freitextfelder, es empfehlen sich Drop-Down-Felder.

  • Es sollte ein Glossar enthalten sein, welches Fachbegriffe (zB „personenbezogene Daten“ oder „sensible Daten“) erklärt.

  • Die Beantwortung sollte nicht mehr als 20 Minuten in Anspruch nehmen. Als Faustregel gelten maximal 30 Fragen.

  • Mit den Fachbereichen sollte ein Training sowie ein Testing stattgefunden haben. Dies ist zB auch mit Hilfe eines sogenannten „Piloten“ möglich.

  • Bei der Konzeption ist die Auswertung der entsprechenden Fragen mit zu berücksichtigen. Es empfiehlt sich eine Datenbanklösung.

  • Der Fragebogen sollte in einem Format gehalten sein, das jeder Adressat öffnen kann.

  • Aus dem Fragebogen sollte sich das nach Art 30 geforderte Verfahrensverzeichnis ableiten lassen.

Der PIA Prozess

Was ist bei Durchführung eines PIA zu tun? Es gibt gegenwärtig keine generell verbindliche Vorgehensweise für die Durchführung von PIAs.

Zweistufiger PIA-Prozess

Wendet man Art 35 DSGVO genau an, so müsste man zunächst die Risikoanalyse durchführen, um sodann – bei entsprechendem Ausgang – eine DSFA mittels PIA durchzuführen. Dies würde in folgendem Ergebnis resultieren: Man wendet sich mit datenschutzrechtlichen Belangen mehrmals an den Fachbereich. Es stellt sich die Frage, wie – besonders in kritischen Situationen – der Fachbereich reagiert. Wir sprechen in diesem Fall von einem sogenannten zweistufigen PIA-Prozess. Je nach Reaktion des Fachbereiches kann allerdings damit die spätere Zusammenarbeit zwischen Fachbereich und Datenschutz erschwert werden.

Besser: Einstufiger PIA-Prozess

Besser dürfte ein „einstufiger Aufbau“ sein: Man stellt im PIA Fragen, welche die eigentliche Risikoanalyse bereits beinhalten, und sendet diese an die Ansprechpartner. Da die DSFA eine jährliche Übung ist, kann man sich dann im zweiten Jahr nur noch auf die Applikationen/Prozesse konzentrieren, die im ersten Jahr als risikobehaftet identifiziert wurden.

In Abbildung 2 wird exemplarisch der Prozess dargestellt. Dies unter Berücksichtigung der zuvor beschriebenen Kriterien der Artikel-29-Gruppe, welche im PIA abgefragt werden:

Abbildung 2: Der PIA-Prozess, © Brockhausen
Abbildung 2: Der PIA-Prozess

Der Bereich PIA/Helpdesk beschreibt hierbei die Einrichtung einer dauernden Hilfestellung. Und zwar sowohl aus rein technischer Sicht als auch aus inhaltlicher.

Technische Möglichkeiten

Wie bereits beschrieben handelt es sich beim PIA um einen Fragebogen. Am Ende sollen sowohl eine Risikoabschätzung als auch ein Bericht stehen.

Zudem ist eine Anforderung der DSGVO ein sog DPMS (Data-Protection-Management-System). Analog zum CMS (Compliance-Management-System) beschreibt das DPMS nicht nur ein IT-System, kann und sollte aber durch entsprechende Anwendungen unterstützt werden.

Im Folgenden werden stichpunktartig technische Möglichkeiten aufgeführt:

  • Nutzung eines SQL Servers

  • Format PIA: Access. Format Access nicht zwingend (möglich auch SharePoint; Oracle Excel usw)

  • Versendet wird ein Link. Ergebnisse werden direkt auf dem Server gespeichert.

  • Technische Identifikation des Adressaten mit zB User ID (jede Applikation/Prozess oder aber auch Projekte werden einem Adressaten zugeordnet)

  • Versendung nebst Reminder gesammelt, workfloworientiert

  • Kontrollen nebst Risikobewertung erfolgen mittels Regeln

  • Verfahrensverzeichnis als Report

Fazit

Es ist unbestritten, dass eine DSFA mittels PIA schon in der Vorbereitung viel Arbeit und Abstimmung bedeutet. Folgt man dem hier vorgeschlagenen Ansatz, so zieht – je nach Anzahl der Applikationen und Prozesse – die Durchführung auch Aufwand mit sich.

Gleichwohl ist eine sorgsam vorbereitete DSFA das Herzstück der Einführung der DSGVO und sorgt nachhaltig dafür, mit Hilfe eines risikobasierten Ansatzes datenschutzrechtlich compliant zu sein.

Autoren

{"uuid":"0872a71e395b45e7a5d635019e9ae144","username":"christian-brockhausen@autorenprofil.at","firstname":"Christian","lastname":"Brockhausen","emailAddress":"christian-brockhausen@autorenprofil.at","created":"2020-07-28T16:12:26.986Z","edited":"2023-10-04T09:08:57.037Z","jobposition":"","fullname":"Christian Brockhausen, MBA","newsletter":true,"salutation":"Herr","pretitle":"","posttitle":"MBA","position":"Compliance","companyname":"","premium":false,"telephone":"","vita":"Christian Brockhausen, MBA ist Principal Consultant bei der Q_PERIOR AG in Frankfurt am Main und verantwortet den Bereich Compliance und Regulatorik. Zudem ist er zertifizierter Datenschutzbeauftragter. Er hält seit Jahren Seminare und publiziert regelmäßig Fachbeiträge.","jet_abo":"","open":true,"profilephoto":{"uuid":"d64a4d3b1f754adc839c033939e94af7","path":"/866_Brockhausen_Christian_(c)_QPerior.jpg","fields":{"name":"866_Brockhausen_Christian_(c)_QPerior.jpg","description":"Christian Brockhausen"}},"path":"https://www.compliance-praxis.at/Insider/Menschen/Person.html?pid=0872a71e395b45e7a5d635019e9ae144"}
866_Brockhausen_Christian_(c)_QPerior.jpg

Christian Brockhausen MBA

Christian Brockhausen, MBA ist Principal Consultant bei der Q_PERIOR AG in Frankfurt am Main und verantwortet den Bereich Compliance und Regulatorik. Zudem ist er zertifizierter Datenschutzbeauftra...

{"name":"Datenschutz: Das optimale „Privacy Impact Assessment“ nach der DSGVO","contenttype":"text/html","templateName":"content-page","headmeta":"<meta charset=\"utf-8\">\n<meta http-equiv=\"X-UA-Compatible\" content=\"IE=edge\">\n<meta name=\"viewport\" content=\"width=device-width, initial-scale=1\">\n\n\n\n\n\n <title>Datenschutz: Das optimale „Privacy Impact Assessment“ nach der DSGVO</title>\n \n\n <meta name=\"description\" content=\"Die EU-Datenschutzgrundverordnung (DSGVO) wird am 25. Mai 2018 wirksam. Gemäß Artikel 35 der Verordnung ist eine Datenschutzfolgeabschätzung (DSFA) durchzuführen. Es fragt sich, wann und mit welchen Instrumentarien dies geschehen soll und vor allem, wie man die DSFA im Unternehmen implementieren kann, ohne den Arbeitsaufwand für die Fachabteilungen unverhältnismäßig zu erhöhen.\"/>\n\n <meta property=\"og:image\" content=\"/templates/test-migration/duplicate-pages/Anonymus-Datenschutz-anonym.jpg\"/>\n <meta property=\"og:image:height\" content=\"564\"/>\n <meta property=\"og:image:width\" content=\"851\"/>\n <meta property=\"og:site_name\" content=\"CompliancePraxis\"/>\n <meta property=\"og:url\" content=\"/Themen/Management_Organisation/Archiv/Datenschutz-_Das_optimale_-Privacy_Impact_Assessment-_nach_.html\"/>\n <meta property=\"og:type\" content=\"website\"/>\n <meta property=\"og:locale\" content=\"de_DE\">\n <meta property=\"og:description\" content=\"Die EU-Datenschutzgrundverordnung (DSGVO) wird am 25. Mai 2018 wirksam. Gemäß Artikel 35 der Verordnung ist eine Datenschutzfolgeabschätzung (DSFA) durchzuführen. Es fragt sich, wann und mit welchen Instrumentarien dies geschehen soll und vor allem, wie man die DSFA im Unternehmen implementieren kann, ohne den Arbeitsaufwand für die Fachabteilungen unverhältnismäßig zu erhöhen.\"/>\n","title":"Datenschutz: Das optimale „Privacy Impact Assessment“ nach der DSGVO","teaser":"Die EU-Datenschutzgrundverordnung (DSGVO) wird am 25. Mai 2018 wirksam. Gemäß Artikel 35 der Verordnung ist eine Datenschutzfolgeabschätzung (DSFA) durchzuführen. Es fragt sich, wann und mit welchen Instrumentarien dies geschehen soll und vor allem, wie man die DSFA im Unternehmen implementieren kann, ohne den Arbeitsaufwand für die Fachabteilungen unverhältnismäßig zu erhöhen.","pagecontent":"<h2>Problemstellung</h2> \n<p> Die Methode einer Datenschutzfolgeabschätzung (DSFA), auf Englisch Privacy Impact Assessment (PIA) genannt, ist im internationalen Vergleich nicht neu, stellt aber aktuell gerade Unternehmen, die bislang keine datenschutzrechtliche Risikoanalyse vorgenommen haben, vielfach vor prozessuale Herausforderungen. Es stellen sich häufig folgende Fragen: </p> \n<p> \n </p><ul> \n <li> <p> Wann ist eine DSFA durchzuführen? </p></li> \n <li> <p> Mit welchen Mitteln kann sie durchgeführt werden? </p></li> \n <li> <p> Welche Möglichkeiten der technischen Umsetzung gibt es? </p></li> \n </ul> \n<h2>Merkmale einer DSFA</h2> \n<p> Eine Datenschutz-Folgenabschätzung </p> \n<p> \n </p><ul> \n <li> <p> beschreibt die Verarbeitungstätigkeit von personenbezogenen Daten, </p></li> \n <li> <p> bewertet deren Notwendigkeit und Angemessenheit und </p></li> \n <li> <p> hilft, die Risiken für die Freiheiten und Rechte natürlicher Personen in den Griff zu bekommen. </p></li> \n </ul> \n<p> Diese Risiken werden bewertet und es werden Maßnahmen zu deren Adressierung festgelegt, das heißt, die Eintrittswahrscheinlichkeit der erkannten Risiken zu minimieren. Die Risikoanalyse ist aufgrund objektiver Kriterien durchzuführen; es werden Faktoren wie Eintrittswahrscheinlichkeit, Schaden sowie Art, Umstände, Umfang und Zweck der Verarbeitung betrachtet. </p> \n<p> Die Eintrittswahrscheinlichkeit richtet sich nach den Erwägungsgründen 90 und 91 der DSGVO und ist aus Sicht des Betroffenen zu beurteilen, wobei die „Risiko-Quelle“ (der Angreifer) zu identifizieren ist. Art 35 DSGVO beschreibt die Schritte hinsichtlich des Vorgehens bei einer DSFA (vgl Abbildung 1). </p> \n<p> </p> <figure class=\"float-none \" style=\"max-width: 50%\" title=\"© Brockhausen\">\n <img src=\"https://www.compliance-praxis.at/GenticsImageStore/627/auto/prop/Themen/Management_Organisation/Archiv/Abb-1_Brockhausen.jpg\" class=\"img-fluid\" alt=\"Abbildung 1: Grundsätzliches Vorgehen bei einer DSFA, © Brockhausen\">\n <figcaption class='text-center'>Abbildung 1: Grundsätzliches Vorgehen bei einer DSFA</figcaption> </figure>\n \n \n \n<p> Somit ist das grundsätzliche Vorgehen das folgende: </p> \n<p> 1.&nbsp; Es ist eine Risikoanalyse vorzunehmen. </p> \n<p> 2.&nbsp; Wo aus der Analyse ein hohes Risiko resultiert, ist eine DSFA zu erstellen, in deren Rahmen auch die technischen, organisatorischen und rechtlichen Maßnahmen darzustellen sind, die dem Risiko bzw der Eintrittswahrscheinlichkeit entgegenwirken („Privacy Controls“). Diese Maßnahmen ergänzen die Datensicherheitsmaßnahmen (Art 32 DSGVO). </p> \n<p> 3.&nbsp; Verbleibt auch nach Durchführung der festgelegten Maßnahmen noch immer („restlich“) ein „hohes Risiko“, dann ist die zuständige Aufsichtsbehörde zu konsultieren. </p> \n<h2>Die Risikoanalyse</h2> \n<p> Es stellt sich zunächst die Frage, wann ein Sachverhalt vorliegt, der datenschutzrechtlich als (hohes) Risiko einzustufen ist. Die DSGVO wird in ihrer Anwendung stets zusammen mit den entsprechenden Erwägungsgründen sowie den Hinweisen der Aufsicht anzuwenden sein. Zur Aufsicht gehören auch Stellungnahmen und Erwägungen der sogenannten Artikel-29-Gruppe. Der Name geht zurück auf Art 29 DSGVO. Die Gruppe stellt das unabhängige Beratungsgremium der Europäischen Kommission für Fragen des Datenschutzes dar. </p> \n<p> Diese Gruppe veröffentlichte vor kurzem Kriterien für das Vorliegen eines datenschutzrechtlichen Risikos. Ein solches liegt demnach in folgenden Fällen vor: </p> \n<p> \n </p><ul> \n <li> <p> Scoring, Profiling, Evaluation, zB Einschätzung der Kreditwürdigkeit, Behavioral Marketing etc, </p></li> \n <li> <p> automatisierte Einzelfallentscheidungen, </p></li> \n <li> <p> systematische Überwachung, </p></li> \n <li> <p> Verarbeitung sensibler Daten, </p></li> \n <li> <p> umfangreiche Datenverarbeitungen (bezogen auf die Anzahl betroffener Personen und Datenkategorien, die Dauer der Verarbeitung, die geographische Ausdehnung), </p></li> \n <li> <p> das Zusammenführen oder Abgleichen von Datenbeständen, wenn Betroffene nicht damit rechnen können, </p></li> \n <li> <p> die Verarbeitung von Daten besonders schutzbedürftiger Personen, </p></li> \n <li> <p> Neuartigkeit von Verarbeitungsvorgängen, Verwendung neuer Technologien (zB Fingerabdrucksensoren oder Gesichtserkennung), </p></li> \n <li> <p> Übermittlung von personenbezogenen Daten an Empfänger außerhalb der EU, </p></li> \n <li> <p> Verarbeitungen, die es betroffenen Personen erschweren, ihre Rechte auszuüben oder eine Leistung in Anspruch zu nehmen, zB die Beurteilung der Kreditwürdigkeit durch eine Bank vor der Vergabe eines Darlehens. </p></li> \n </ul> \n<p> Als „Faustregel“ wurde beschrieben, dass bei Vorliegen von mindestens zwei dieser Kriterien ein Risiko vorliegt, das eine DSFA rechtfertigt. </p> \n<h2>Das Mittel für die DSFA</h2> \n<p> Es hat sich vielfach etabliert, eine derartige Risikoanalyse mit Hilfe eines sogenannten Privacy Impact Assessments (PIA) durchzuführen. </p> \n<p> <b>Was ist ein Privacy Impact Assessment (PIA)?</b> </p> \n<p> Ein Privacy Impact Assessment (PIA) ist eine systematische Analyse der Auswirkungen einer Anwendung auf Privatsphäre und Datenschutz. Eine PIA stellt somit eine Datenschutzfolge- und Risiko-Abschätzung dar. PIAs sind seit einigen Jahren im englischsprachigen Raum gebräuchlich. In der Regel handelt es sich um einen Fragebogen (Questionnaire), welcher Fragen enthält, aus deren Antworten sich die zuvor beschriebenen Risiken ableiten lassen, aber auch adressieren lassen, um entsprechende Gegenmaßnahmen einzuleiten. </p> \n<p> Anwendungsbereich eines derartigen PIA sind die Applikationen, aber auch die Prozesse eines Unternehmens. Gerade aus den Letzteren lässt sich bei entsprechender Konzeption das in Art 30 DSGVO geforderte Verfahrensverzeichnis ableiten. </p> \n<p> <b>Inhalt des PIA</b> </p> \n<p> Wie zuvor beschrieben dient das PIA der Risikoanalyse. Diese kann nur unternehmensindividuell durchgeführt werden. Gleichwohl gibt es Sachverhalte, die ein PIA auf jeden Fall abfragen sollte: Es empfiehlt sich zunächst einmal abzufragen, ob das System oder der Prozess personenbezogene Daten verarbeitet. Hinzu kämen – nimmt man als Anhaltspunkt die Kriterien der Artikel-29-Gruppe – Fragen nach den jeweiligen Sachverhalten wie etwa Datenübertragung in Länder außerhalb der EU; Verwendung von Gesundheitsdaten usw. Denkbar wäre es, noch Fragen von grundsätzlichem Interesse einzufügen. Denkbar wäre hier der Punkt der Vertraulichkeitserklärungen. </p> \n<p> Wie zuvor beschrieben ist immer der Geschäftszweck des Unternehmens bzw seine Kundenstruktur in die Überlegungen mit einzubeziehen. </p> \n<p> <b>Wer ist Adressat eines PIA?</b> </p> \n<p> Bei dieser Frage empfiehlt es sich, in der Vorbereitung eines PIA-Fragebogens erhöhte Aufmerksamkeit walten zu lassen. Führt man sich nämlich die jeweiligen Rollen eines Unternehmens vor Augen, so ist diese Frage nicht einfach zu beantworten. </p> \n<p> Die lediglich für eine IT-Applikation verantwortliche Person wird bspw kaum beantworten können, ob ein System Gesundheitsdaten benutzt oder nicht. </p> \n<p> Man benötigt demnach Adressaten aus den Fachbereichen, die tatsächlich mit der Applikation arbeiten. Je nach Rollenmodell des Unternehmens können dies sogenannte „Business Application Owner“ sein. </p> \n<p> Bei der ersten Durchführung eines PIA empfiehlt es sich, genügend Zeit einzuplanen. In der Regel dürfte man im Zuge der Ermittlung des Adressaten auch auf ungeklärte Fragen im Rahmen des Rollen- und Berechtigungskonzeptes stoßen. </p> \n<p> <b>Anforderungen an ein PIA</b> </p> \n<p> Es stellt sich die Frage, welchen Anforderungen ein PIA genügen muss. Dies insbesondere im Hinblick auf den Adressaten. Es gilt nämlich, den Arbeitsaufwand für den Fachbereich so gering wie möglich zu halten. Dies erhöht nicht zuletzt auch das Bewusstsein für das Thema Datenschutz. </p> \n<p> Grundsätzlich gilt das Folgende: </p> \n<p> \n </p><ul> \n <li> <p> Durchführung des PIA sowohl für Applikationen als auch Prozesse; </p></li> \n <li> <p> Anwendung einer einfachen, auch vom datenschutzrechtlichen Laien zu verstehenden Sprache; </p></li> \n <li> <p> je nach Unternehmensausrichtung Mehrsprachigkeit; </p></li> \n <li> <p> so wenig wie möglich Freitextfelder, es empfehlen sich Drop-Down-Felder. </p></li> \n <li> <p> Es sollte ein Glossar enthalten sein, welches Fachbegriffe (zB „personenbezogene Daten“ oder „sensible Daten“) erklärt. </p></li> \n <li> <p> Die Beantwortung sollte nicht mehr als 20 Minuten in Anspruch nehmen. Als Faustregel gelten maximal 30 Fragen. </p></li> \n <li> <p> Mit den Fachbereichen sollte ein Training sowie ein Testing stattgefunden haben. Dies ist zB auch mit Hilfe eines sogenannten „Piloten“ möglich. </p></li> \n <li> <p> Bei der Konzeption ist die Auswertung der entsprechenden Fragen mit zu berücksichtigen. Es empfiehlt sich eine Datenbanklösung. </p></li> \n <li> <p> Der Fragebogen sollte in einem Format gehalten sein, das jeder Adressat öffnen kann. </p></li> \n <li> <p> Aus dem Fragebogen sollte sich das nach Art 30 geforderte Verfahrensverzeichnis ableiten lassen. </p></li> \n </ul> \n<h2>Der PIA Prozess</h2> \n<p> Was ist bei Durchführung eines PIA zu tun? Es gibt gegenwärtig keine generell verbindliche Vorgehensweise für die Durchführung von PIAs. </p> \n<p> <b>Zweistufiger PIA-Prozess</b> </p> \n<p> Wendet man Art 35 DSGVO genau an, so müsste man zunächst die Risikoanalyse durchführen, um sodann – bei entsprechendem Ausgang – eine DSFA mittels PIA durchzuführen. Dies würde in folgendem Ergebnis resultieren: Man wendet sich mit datenschutzrechtlichen Belangen mehrmals an den Fachbereich. Es stellt sich die Frage, wie – besonders in kritischen Situationen – der Fachbereich reagiert. Wir sprechen in diesem Fall von einem sogenannten zweistufigen PIA-Prozess. Je nach Reaktion des Fachbereiches kann allerdings damit die spätere Zusammenarbeit zwischen Fachbereich und Datenschutz erschwert werden. </p> \n<p> <b>Besser: Einstufiger PIA-Prozess</b> </p> \n<p> Besser dürfte ein „einstufiger Aufbau“ sein: Man stellt im PIA Fragen, welche die eigentliche Risikoanalyse bereits beinhalten, und sendet diese an die Ansprechpartner. Da die DSFA eine jährliche Übung ist, kann man sich dann im zweiten Jahr nur noch auf die Applikationen/Prozesse konzentrieren, die im ersten Jahr als risikobehaftet identifiziert wurden. </p> \n<p> In Abbildung 2 wird exemplarisch der Prozess dargestellt. Dies unter Berücksichtigung der zuvor beschriebenen Kriterien der Artikel-29-Gruppe, welche im PIA abgefragt werden: </p> \n<p> </p> <figure class=\"float-none \" style=\"max-width: 50%\" title=\"© Brockhausen\">\n <img src=\"https://www.compliance-praxis.at/GenticsImageStore/608/auto/prop/Themen/Management_Organisation/Archiv/Abb-2_Brockhausen.jpg\" class=\"img-fluid\" alt=\"Abbildung 2: Der PIA-Prozess, © Brockhausen\">\n <figcaption class='text-center'>Abbildung 2: Der PIA-Prozess</figcaption> </figure>\n \n \n<p>Der Bereich PIA/Helpdesk beschreibt hierbei die Einrichtung einer dauernden Hilfestellung. Und zwar sowohl aus rein technischer Sicht als auch aus inhaltlicher. </p> \n<h2>Technische Möglichkeiten</h2> \n<p> Wie bereits beschrieben handelt es sich beim PIA um einen Fragebogen. Am Ende sollen sowohl eine Risikoabschätzung als auch ein Bericht stehen. </p> \n<p> Zudem ist eine Anforderung der DSGVO ein sog DPMS (Data-Protection-Management-System). Analog zum CMS (Compliance-Management-System) beschreibt das DPMS nicht nur ein IT-System, kann und sollte aber durch entsprechende Anwendungen unterstützt werden. </p> \n<p> Im Folgenden werden stichpunktartig technische Möglichkeiten aufgeführt: </p> \n<p> \n </p><ul> \n <li> <p> Nutzung eines SQL Servers </p></li> \n <li> <p> Format PIA: Access. Format Access nicht zwingend (möglich auch SharePoint; Oracle Excel usw) </p></li> \n <li> <p> Versendet wird ein Link. Ergebnisse werden direkt auf dem Server gespeichert. </p></li> \n <li> <p> Technische Identifikation des Adressaten mit zB User ID (jede Applikation/Prozess oder aber auch Projekte werden einem Adressaten zugeordnet) </p></li> \n <li> <p> Versendung nebst Reminder gesammelt, workfloworientiert </p></li> \n <li> <p> Kontrollen nebst Risikobewertung erfolgen mittels Regeln </p></li> \n <li> <p> Verfahrensverzeichnis als Report </p></li> \n </ul> \n<h2>Fazit</h2> \n<p> Es ist unbestritten, dass eine DSFA mittels PIA schon in der Vorbereitung viel Arbeit und Abstimmung bedeutet. Folgt man dem hier vorgeschlagenen Ansatz, so zieht – je nach Anzahl der Applikationen und Prozesse – die Durchführung auch Aufwand mit sich. </p> \n<p> Gleichwohl ist eine sorgsam vorbereitete DSFA das Herzstück der Einführung der DSGVO und sorgt nachhaltig dafür, mit Hilfe eines risikobasierten Ansatzes datenschutzrechtlich compliant zu sein. </p>","sidecolumn":null,"storiesmain":null,"storiesoverview":null,"headerimage":"","headertitle":"<h1 class=\"contentheader \">Datenschutz: Das optimale „Privacy Impact Assessment“ nach der DSGVO</h1>","stoerercontainer":null,"stoerercontainer2":null,"stoererwerbebanner":"","insiderheads":null,"overviewunternehmenimage":null,"overviewunternehmentitle":null,"buttonviewall1":null,"buttonviewall2":null,"superelement":null,"topstory":null,"netzwerkpartnerlogoleiste":"","metadata":"<div class=\"info\"><eval>>partials/themes-startpage/newsauthors data=(renderNewsAuthors \"138\" userinfo)</eval>\n<br>01. September 2017 / Erschienen in Compliance Praxis 3/2017, S. 19</div>","footnotes":"<div class=\"footnote v-spacer footnote-editor-preview d-none\"></div>\n","eventsmain":null,"eventsoverview":null,"eventsoverviewjson":null,"event":"","eventdates":"000-000","footer":"<footer class=\"d-flex flex-column flex-xl-row\">\n\t<span class=\"sr-only\">Footer</span>\n\t<ul class=\"nav footer-nav flex-row pb-4 pb-xl-0 w-100\" id=\"footernavigation\" role=\"navigation\">\n\t\t\t\t\t\t\t</ul>\n\t<div class=\"copyright flex-md-shrink-1 text-left text-md-right\">\n\t\t\t\t<img src=\"/static/compliance_praxis/files/images/LexisNexis.png\" alt=\"LexisNexis\">\n\t\t<p></p>\t</div>\n</footer>\n","footerglobal":"<eval>{cpConfigLoader \"global\" \"footer\"}</eval>","footerjson":null,"onetrust":null,"ogimagefallback":null,"ogimagefallbackheight":null,"ogimagefallbackwidth":null,"cpcouponlist":null,"taggedthemes":["Datenschutz","Compliance Organisation","Richtlinien"],"taggedcategories":["Management & Organisation"],"taggedorganizers":[],"taggedexhibitors":[],"taggedlecturers":[],"taggedmoderators":[],"taggedparticipants":[],"taggedauthors":["138"],"taggedmagazine":["Compliance Praxis 3/2017"],"taggedmagazinepage":"19","taggedadvertorial":[],"taggingcontainer":null,"authorsdetails":"<div><eval>>partials/content-page/authorsdetails</eval></div>","participantsdetails":null,"contactsdetails":null,"portalapp":"cpshop,cprelatedarticles,","sidecolumninsider":null,"sidecolumnthemen":null,"sidecolumnevents":null,"sidecolumnglobal":"\t<eval>{cpConfigLoader \"stoerer\" \"sidecolumnthemen\"}</eval>\n\t\t\t\t\t\t<eval>> partials/applications/cprelatedarticles applicationtag=\"cprelatedarticles\"</eval>\n\t\t\t","sidecolumntop":"<div class=\"row\"></div>","sidecolumnbottom":"<div class=\"row\"></div>","premium":null,"oecov":null,"textimage":null,"upcompanytaggedevents":null,"upcompanyadvertorialarticles":null,"personprofile":null,"cms_id":1352,"usermodule":null,"cpuseraccount":null,"meshroles":["anonymous"],"taggingusers":null,"magentoshopapp":"\n"}