2 Datenfluss und Verantwortlichkeiten visualisieren
2 Datenfluss und Verantwortlichkeiten visualisieren
Ziel dieser Komponente ist die Erstellung von:
- Szenarien, die alle relevanten Datenflüsse beschreiben
- Datenflussdiagramm der Abläufe mit den relevanten Akteur:innen
Benötigte Vorlagen:
Die meisten Mobilitätsdaten-Projekte sind dynamisch. Sie enthalten Prozesse, in denen Daten zwischen verschiedenen Kontexten, den sogenannten
Wir sprechen von einem Datenfluss, wenn ein Prozess im Projekt mindestens eins der folgenden vier Elemente ändert:
- Akteur:innen: Mit welchem Prozess ändert sich etwas an den Personen, die Zugriff auf die Daten haben oder Verantwortung über die Daten übernommen haben?
Insbesondere sollten hier die Personen in den folgenden drei Rollen in Betracht gezogen werden- The fallback content to display on prerendering: Wer waltet momentan über die Daten?
- The fallback content to display on prerendering: Wer verändert die Daten innerhalb des Projekts?
- The fallback content to display on prerendering: Wer nutzt die Daten letztendlich?
- Governance-Prozesse: Mit welchem Prozess ändert sich etwas daran, wie der Zugriff auf die Daten geregelt wird?
Beispiel: Welche Datenschutzdokumente werden für die Daten verwendet? - Infrastruktur: Mit welchem Prozess ändert sich, wie die Daten technisch oder organisatorisch verwaltet werden?
Beispiel: Auf welchem Server sind die Daten gespeichert und welche Organisation kontrolliert die Daten? - weitere Datensätze: Ändert sich etwas an den Datensätzen, mit denen die Daten in Verbindung gebracht werden können?
Beispiel: Verhindert eine Anonymisierung, dass die Daten mit weiteren Datensätzen referenziert werden können?
Für das Datenflussdiagramm wird zunächst nur eine oberflächliche Beschreibung dieser Eigenschaften benötigt, mit einem Fokus auf die Änderungen der Eigenschaften, die den jeweiligen Datenfluss charakterisieren. Eine detaillierte Beschreibung der Eigenschaften wird dann in der folgenden Komponente erstellt, um schließlich die Risiken und erforderlichen Schutzmaßnahmen in jeder Datenumgebung korrekt zu bewerten.
Datenflüsse identifizieren
Im ersten Schritt müssen mögliche Datenflüsse in dem angestrebten Mobilitätsdaten-Projekt identifiziert werden. Es ist wichtig alle Datenflüsse zu identifizieren und kritisch zu betrachten, da sich bei einem Datenfluss die Schutzmechanismen oder die Zuständigkeiten für die Daten ändern.
Ein Datenfluss kann beispielweise zwischen zwei Abteilungen innerhalb einer Organisation oder zwischen zwei verschiedenen Organisationen erfolgen. Im Falle einer Datenveröffentlichung gibt es einen Datenfluss an die Allgemeinheit. Datenflüsse können aber auch innerhalb einer Abteilung auftreten, wenn beispielsweise die Anonymisierung weiter einschränkt mit welchen weiteren Daten die betreffenden Daten verknüpft werden können oder welche Regularien (Datenschutzdokumente, Datenschutzverordnungen) auf die Daten angewandt werden müssen.
Typischerweise besteht solch ein Mobilitätsdaten-Projekt aus einem primären Datenfluss, der bereits im Steckbrief des Projekts beschrieben wird. Um auch alle weiteren Datenflüsse zu identifizieren ist es hilfreich, die Informationen aus dem Steckbrief zu einem Szenario zu erweitern, das einen möglichen Lauf des Projekts im Detail beschreibt. Dieses Szenario wird in den nächsten Komponenten weiter angereichert.
Szenario
Ein Szenario ist eine narrative Beschreibung eines typischen Ablaufs im Rahmen des Mobilitätsdaten-Projekts, basierend auf dem Steckbrief des Projekts aus Komponente 1. Je konkreter ein Szenario ist, desto besser können Informationen über das Projekt abgeleitet werden. Wichtige Informationen sind, wer in welcher Rolle welche Daten hat und wie verarbeitet.
Je nach Kontext können alle Datenflüsse eines Projekts in einem Szenario beschrieben werden. Andere Projekte wiederum sind einfacher zu erfassen, wenn sie in mehrere separate Szenarien aufgeteilt werden. Dabei beschreibt jedes Szenario andere Datenflüsse, die in dem Projekt auftreten können.
Die Erstellung eines Szenarios beginnt mit den Informationen aus dem Steckbrief aus Komponente 1, aber enthält zusätzliche Informationen zum Kontext der Daten und bildet den Prozess ganzheitlich von den aktuellen Datenverwalter:innen bis hin zu den Datennutzer:innen ab. Szenarien dürfen narrativ sein, da dies hilft, relevante Datenflüsse besser zu charakterisieren.
Szenario 1
Das Shared Mobility-Unternehmen Scoooot teilt seine Nutzungsdaten aus der App zum Verleih von E-Scootern mit dem regionalen ÖPNV-Unternehmen, das für die Bereitstellung von Mobility Hubs für die Förderung intermodaler Mobilität verantwortlich ist. Durch den Kooperationsvertrag besteht eine Verpflichtung zur Übermittlung der Scoooot Mobilitäts-Daten an das ÖPNV-Unternehmen. Vor der Übermittlung werden die Daten zunächst pseudonymisiert, also die Namen und IDs der Kunden durch nicht mehr zuordenbare Pseudonyme ersetzt. Das Unternehmen Scoooot nutzt einen Dienstleister DB.it zum Betreiben der App, der entsprechend die Rohdaten speichert.
Daher beauftragt Scoooot den Dienstleister DB.it den angeforderten Teil der Daten in einem geeigneten Format als Export bereitzustellen. DB.it kommt dieser Anfrage nach und sendet den Export an Scoooot. Scoooot verifiziert, dass die Daten korrekt exportiert wurden und wendet eine angemessen Pseudonymisierung an. Danach werden die pseudonymisierten Daten von Scoooot an das ÖPNV-Unternehmen weitergeleitet.
In unserem Beispiel genügt dieses eine Szenario, um den Datenfluss zu beschreiben. Hätte Scoooot verschiedene Dienstleister, um zum Beispiel die App für verschiedene Plattformen bereitzustellen, könnten die Datenflüsse in verschiedene Szenarien geteilt werden.
Datenflüsse visualisieren
Im zweiten Schritt werden mithilfe der Szenarien die auftretenden Datenflüsse spezifiziert und in einem Datenflussdiagramm visualisiert. Um jeden Datenfluss zu charakterisieren, werden auch Eigenschaften der übergebenen Daten in dem Datenflussdiagramm hinterlegt, sowie die verantwortlichen Akteur:innen und die grundlegenden Eigenschaften der Datenumgebung vor und nach dem Datenfluss (in den Datenumgebungen). Hierbei ist es hilfreich, den involvierten Akteur:innen die Rollen richtig zuzuordnen: Datenverwalter:innen, Datenverarbeiter:innen und Datennutzer:innen.
Die Abbildung des Datenflusses ermöglicht es, die Datenlage visuell nachzuvollziehen und leichter zu bestimmen, auf welche Datenflüsse man sich besonders fokussieren sollte. Hierbei ist insbesondere wichtig, wer die Kontrolle über relevante Umgebungen hat (Verortung der Kontrolle), beziehungsweise (indirekt) verantwortlich ist (Verortung der Verantwortlichkeit).
Datenflussdiagramm
Die hier genutzten Datenflussdiagramme sind angelehnt an Sequenzdiagramme, die im UML Standard definiert sind. Um ein Datenflussdiagramm zu erstellen, wird zunächst eine Spalte pro Datenumgebung angelegt und als vertikaler Strich symbolisiert. Die identifizierenden Informationen über die Datenumgebung (Akteur:innen, weitere Datensätze, Infrastruktur oder Governance) werden in den Kopf der Spalte eingetragen. Die identifizierten Datenflüsse von einer Datenumgebung in eine andere Datenumgebung werden als horizontale Pfeile zwischen den entsprechenden Spalten eingetragen. Die Pfeile werden weiter mit den Eigenschaften der ausgetauschten Daten beschriftet.
Die zeitliche Abfolge der Datenflüsse ist für die Analyse der Datenumgebungen zwar weniger relevant, aber eine Anordnung der Datenflüsse von oben nach unten in zeitlicher Reihenfolge entsprechend der Szenarien ist dennoch sinnvoll, um sicherzustellen, dass alle Datenflüsse in das Diagramm eingetragen wurden.
Datenflüsse können auch in eine Datenumgebung zurückführen, in der sie bereits verarbeitet wurden. Dann muss aber genau geprüft werden, ob sich nicht doch eine der vier Aspekte geändert hat, zum Beispiel die Verknüpfung zu anderen Datensätzen.
Wenn die Situation der Datenflüsse im ersten Teil in mehrere Szenarien aufgeteilt wurde, können diese entweder in einem Datenflussdiagramm kombiniert werden, oder in separaten Diagrammen visualisiert werden. Wichtig ist nur, dass alle Datenflüsse erfasst werden.
In unserem Beispiel lassen sich drei Datenflüsse identifizieren.
- Der erste Datenfluss ist bestimmt durch die Übergabe der Daten von dem Dienstleister DB.it (Datenverarbeiter:innen) an Scoooot. Durch diese Übergabe ändern sich die Akteur:innen, die auf die Daten zugreifen können und ihre Verantwortlichkeit, sowie die Infrastruktur (sowohl technisch als auch organisatorisch), in der die Daten gespeichert sind.
- Der zweite Datenfluss entsteht durch die Pseudonymisierung innerhalb von Scoooot (Datenverwalter:innen), da die Pseudonymisierung einschränkt, mit welchen weiteren Datensätzen die Daten verknüpft werden können.
- Der dritte Datenfluss stellt die Übergabe der pseudonymisierten Daten in die Verantwortlichkeit des ÖPNV-Unternehmens (Datennutzer:innen) dar. Hier ändern sich sowohl die Akteur:innen, die Infrastruktur als auch die Governance-Dokumente, falls eine Datenvereinbarung zwischen Scoooot und dem ÖPNV-Unternehmen die Datennutzung regelt. Potenziell kommen hier auch weitere Datensätze des ÖPNV-Unternehmens hinzu, die mit den Daten verknüpft werden können.
Die Fokus ist hier auf dem Datenfluss von Datenumgebung 3 in die Datenumgebung 4, da hier die Daten in die Kontrolle des Dritten (ÖPNV-Anbieter) übergehen und somit die Situation am kritischsten ist.