Partner-Post Schritt für Schritt zum Privacy Impact Assessment

Datenschutz: Wie aus einer Notwendigkeit ein Wettbewerbsvorteil wird

Uhr
von Thomas Bader, Senior Security Consultant, Terreactive

Kunden erwarten heute den Schutz ihrer persönlichen Daten und ihrer Privatsphäre. Unternehmen, die dies rechtzeitig ­planen, erzielen nicht nur einen Wettbewerbsvorteil, sie können auch Kosten vermeiden. Privacy ist keine leichte Aufgabe – doch es gibt ein bewährtes Hilfsmittel.

Thomas Bader, Senior Security Consultant, Terreactive. (Source: stefanie fretz)
Thomas Bader, Senior Security Consultant, Terreactive. (Source: stefanie fretz)

Privacy ist ein Thema, das in der IT immer mehr zur Sprache kommt. Berichte über missbräuchliche Datenverarbeitung und Data-Breaches sowie der vermehrte Einbezug der Cloud bei der digitalen Transformation führen zu immer höheren Ansprüchen an den Datenschutz. Mit der Datenschutz-Grundverordnung der EU ­(DSGVO) kommen hohe rechtliche Anforderungen hinzu.

Viele Firmen sind verunsichert, ob sie die Anforderungen an den Datenschutz erfüllen. Je nach Umfeld müssen sie dem Schweizer Datenschutzgesetz (DSG), der DSGVO sowie weiteren Vorgaben gerecht werden. Das Privacy Impact Assessment (PIA) hilft dabei, Risiken zu analysieren und transparent auszuweisen. Dabei wird eine Impact-Analyse erstellt und anhand des standardisierten Report­umfangs kann dem Kunden verständlich die Verarbeitung und der Schutz seiner Daten aufgezeigt werden. Wer bereits Erfahrung mit Risikoanalysen hat, findet im PIA einige neue Aspekte, wird sich jedoch schnell zurechtfinden.

Alles beginnt mit den Daten

Das PIA sollte möglichst früh in einem Projekt beginnen − vorzugsweise bereits in der Planungsphase. Ein PIA ist notwendig, sobald sensible PII (Personally Identifiable Information) verarbeitet werden. Dabei handelt es sich gemäss ISO 29100 um Daten, durch die eine natürliche Person (der PII Principal) identifizierbar wird, Rückschlüsse auf ihre persönliche Situation gezogen werden können oder ihr in einer anderen Form Schaden entstehen kann. Aufgrund rechtlicher und regulatorischer Vorgaben zählen auch Daten zur Gesundheit oder zu politischen Ansichten als sensibel und besonders schützenswert. Banken, Spitäler und Versicherungen haben zudem ein weitergehendes Verständnis von Datenschutz, und in der EU zählen durch die DSGVO sogar Tracking-Cookies zu den relevanten Daten.

Vor dem Entscheid, ob ein PIA durchgeführt wird, ist also ein Blick auf Gesetze und Regulationen notwendig. Will man ein PIA nach anerkanntem Vorgehen durchführen, orientiert man sich am Standard ISO 29134 − den Guide­lines for Privacy Impact Assessment.

Beurteilung des Schadensausmasses

Wer bereits Risk-Assessments durchgeführt hat, kennt das Schadensausmass bei der Bewertung des Risikos: Es wird beurteilt, wie hoch ein Schaden quantitativ ausfallen kann oder wie er sich qualitativ klassifizieren lässt. Beim PIA ist es ähnlich: Welchen Schaden könnte ein Privacy-Breach dem PII Principal zufügen?

Der PII Controller des Unternehmens (er ist verantwortlich für die Einhaltung der Vorschriften) muss dazu einen Fokuswechsel vornehmen: Die Beurteilung erfolgt nicht angesichts der eigenen Organisation, sondern er muss sich in den PII Principal hineinversetzen. Deshalb sollte das Risiko-Assessment in der Informationssicherheit und in der Privacy auch getrennt erfolgen, da dieselbe Schwachstelle in den unterschiedlichen Kontexten möglicherweise anders beurteilt werden muss.

Da diese Sichtweise sehr abstrakt ist, empfiehlt der ISO-Standard, von einem Level of Impact zu sprechen. Dies ist eine qualitative Beurteilung, die abbildet, durch wie viel Eigenaufwand der PII Principal den Schaden aus eigener Kraft bewältigen kann.

Die Tabelle zeigt den Level of Impact mit einem Beispiel und einem Vergleich mit Datenklassifizierungsstufen. (Quelle: terreActive)

Assets identifizieren

Zu Beginn des PIA ist es wichtig, den Umfang (Scope) richtig zu bestimmen, was typischerweise durch eine Analyse der Business-Cases und Bestimmung der Assets geschieht. Basierend darauf wird eine Schematik der Pfade der Datenverarbeitung erstellt (Data Flows, Verarbeitungskette) und das mögliche Verhalten der User (Use Cases, Nutzungsverhalten) bestimmt. Um die Data Flows zu identifizieren, sind folgende Fragen zu beantworten:

  • Sammlung: Wo und wie werden Daten erhoben?

  • Übertragung: Zwischen welchen Systemen werden Daten übertragen?

  • Speicherung: Wo und wie werden Daten gespeichert?

  • Nutzung: Wo werden die Daten verarbeitet?

  • Löschung: Wann und wo werden Daten gelöscht?

Danach werden im PIA für die möglichen Kombinationen von Data Flows und Use Cases die potenziellen Schäden bestimmt. Hier unterscheidet sich das PIA vom klassischen Risk Assessment der Informationssicherheit, da die Interaktion des Benutzers mit dem System sowie die stattfindende Datenverarbeitung im Fokus stehen. Im PIA soll daher nicht nur das technische Personal zur Analyse einbezogen werden, sondern auch die Business- und Sales-Abteilungen.

Anforderungen an die Datenverarbeitung

Das PIA verlangt auch, die Privacy Safeguarding Requirements zu erfassen, also die Anforderungen an den Datenschutz aus rechtlicher und regulatorischer Sicht sowie branchenspezifische Vorgaben. Hier wird der Bezug zum Schweizer DSG und zur DSGVO gemacht, weshalb auch juristische Fachkräfte einbezogen werden sollen. Wenn dies sorgfältig ausgeführt wird, kann das Resultat bei zukünftigen Assessments wiederverwendet werden.

Das PIA erwartet zusätzlich eine Beurteilung, ob die Erfassung der Daten hinsichtlich der zu erbringenden Dienstleistung notwendig ist. Im Rahmen der DSGVO ist dies zentral, wie der Umgang mit Cookies zeigt.

Die Privacy Risk Map

Für das PIA benötigt man eine Liste der möglichen Bedrohungen. Der Standard enthält eine Vorlage dazu. Eine ­Bedrohung kann eine Schwachstelle oder ein Fehler im Betrieb des Servers sein, die zu unerlaubtem Zugriff oder zum Verlust von PII führen.

Sind alle Informationen verfügbar, wird daraus eine Privacy Risk Map gezeichnet. Die Ermittlung der Eintretenswahrscheinlichkeit kann auf die gleiche Weise erfolgen wie beim Risk-Assessment in der Informationssicherheit. Bei der Privacy Risk Map und dem Register der Privacy Risks gilt es dann noch zu bestimmen, wo genau die Risikoakzeptanzlinie verläuft, und gegebenenfalls die Schutzmassnahmen zu definieren. Wer dies von der Informationssicherheit her schon kennt, kann wie gewohnt vorgehen.

Die Grafik illustriert ein mögliches Beispiel einer Privacy Risk Map. (Quelle: terreActive)

Ein Schweizer Taschenmesser für den Datenschutz

Sind die Privacy-Risiken im Unternehmen identifiziert und die notwendigen Schutzmechanismen definiert, dient das PIA und der ISO-Standard darüber hinaus als Grundlage für einen strukturierten Report zum Nachweis der eigenen Anstrengungen zum Datenschutz. Dieser Report enthält:

  • Scope & Anforderungen

  • Angaben zum Zweck der Datenverarbeitung

  • Beschreibung der Datensammlung und Verarbeitung

  • Die Pfade der Datenverarbeitung

  • Regelung der Zugriffsrechte

  • Identifizierte Risiken

  • Angewendete Schutzmassnahmen

Der ISO-Standard enthält eine Vorlage für eine mögliche Struktur, die auch die Erstellung unterschiedlicher Editionen pro Zielgruppe erlaubt und die das Unternehmen als Basis für eine eigene Vorlage nutzen kann. Wer basierend auf dem Report beispielsweise eine vereinfachte Version zu Händen der Kunden generieren kann, ist in der Lage, die unternommenen Anstrengungen zu dokumentieren und etwa bei der Teilnahme an einer Ausschreibung einzureichen. Damit ist das PIA nicht nur ein zentrales Hilfsmittel für die Gewährleistung eines wirksamen und kosteneffizienten Datenschutzes im Unternehmen, es liefert ausserdem einen Wettbewerbsvorteil in einer Geschäftswelt, aus der Datenschutz nicht mehr wegzudenken ist.

Die Grafik zeigt, wie ein PIA abläuft. Hier wird auch der PIA Report aufgeführt, dessen Erstellung vom ISO 29134 verlangt wird. (Quelle: terreActive)

Aus der Praxis: Zusammenhang – Privacy ­Impact Assessment und Security Operations Center

Durch das Privacy Impact ­Assessment (PIA) nimmt ein Unternehmen die Sicht des Kunden ein und lernt die Risiken aus dessen Sicht kennen. Das Security Operations Center (SOC) kann darauf basierend Use-Cases entwickeln, die Datenschutzverletzungen überwachen und notfalls Alarm schlagen. Dadurch erhält der Kunde eine Stimme, da seine Bedürfnisse in der Priorisierung und der Erarbeitung der Schutzmassnahmen und dem Monitoring mehr ­Gewicht ­erhalten.

Webcode
DPF8_205292