Ich sehe da immer eine rechte Streuung wenn ich mir öffentliche DSFAs anschaue…
(zB Covid19 App Jersey - 30 Seiten gegenüber 190 Seiten der deutschen CWA App DSFA… und ich weiss nicht ob die zweite unbedingt überall besser ist… )
Vielleicht lernen wir ja aus der gemeinsamen Diskussion.
Es ist die Frage, ob die DSFA von einem Rechtsanwalt, einem Organisator oder einem Techniker geschrieben wurde. Rechtsanwälte neigen zu Wortdrechselei und extremem Detailreichtum, meistens ohne die Technik wirklich zu verstehen.
Organisatoren vernachlässigen bisweilen die rechtlichen Aspekte und Techniker, nun die verstehen von Juristerei gar nichts und sind knapp und wortsparsam.
Ich habe selbst gerade eine DSFA in Arbeit für eine FOSS Lernplattform in der beruflichen Fortbildung und schätze mal, dass für eine ordentliche und saubere DSFA mit Beschreibung, Risikoabschätzung und Bewertung gar nicht so viele Seiten notwendig sind. Was aber zwingend dazu gehört, sind dann die technischen und organisatorischen Anweisungen, die bei den Installationsparametern anfangen und bei Aufbewahrungszeiten oder dem Umgang mit dem Chat aufhören.
Was dabei auch noch ins Auge sprang, war die absolute Notwendigkeit, in die technischen Konzepte und Strukturen der Software schauen zu können, denn im Design entscheiden sich sehr wesentlich die Ausprägungen der Risiken. Z.B. sind zentrale oder dezentrale Speicherstrategien, die Aufteilung von Datenbanktabellen und die Abbildung des Datenmodells sehr entscheidend für manche praktischen Auswirkungen. Da hilft FOSS ungemein.
Der eigentlich richtige Weg aber wäre es, die DSFA wirklich zweistufig durchzuführen:
Schritt 1 vor der Beschaffung der technischen Lösung und
Schritt 2 bei der Auswahl der technischen Lösung
Mit dieser Reihenfolge wird man nicht nur dem Datenschutz optimal gerecht, sondern gewinnt auch noch viel bessere Einblicke und Entwicklungsmöglichkeiten für betriebsinterne Strukturen und Abläufe.
Sehr interessant und umfassend, was die Systeme angeht. Gerade heute hat ein IT-Beratungslehrer festgestellt, dass wir so etwas in Deutschland bräuchten. Er nannte es Whitelist der schulischen Digitalsysteme, was natürlich auch eine Bewertung einschließt.
Ich finde 190 Seiten wenig zielführend. Angesichts der Schwierigkeiten, die die Leute bereits mit einem normalen Verarbeitungsverzeichnis haben, frage ich mich, wer das in welcher Zeit schreiben und lesen soll. Und warum sollte man Unmengen von Fließtext in einer DSFA unterbringen, wenn es darum geht, das Wesentliche schnell erfassen zu können? Dafür reichen doch aussagekräftige Stichpunkte.
Hier ist ein Beispiel (ca. 50 Seiten) für ein Krankenhaus-Informationssystem, inkl. nutzbarer Vorlagen unter CC BY-SA Lizenz. Gute Idee. https://gesundheitsdatenschutz.org/html/dsfa-beispiel.php
Im Krankenhaus “Himmelstor” ist Kirk der DSB, Scotty der IT-Leiter und Chekov der IT-SiBe.
Danke für den link zum Himmelstor. - Generell eine sehr interessante Webseite.
Bei den Risiken stört es mich immer ein bischen wenn die Auswirkungen (physisch/moralisch/materiell) auf die Betroffenen nicht ausgeführt werden.
Im Beispiel “Himmelstor” sind (per Versicherung) Zahlungen an die Betroffenen vorgesehen.
Nur hilft das nichts, wenn diese arm dran sind, weil der falsche Arm ab ist… (Krankenhaus-IS)
oder das ganze Dorf vom Schwangerschaftsabbruch weiss…
190 Seiten finde ich auch grenzwertig (wie gesagt, Rechtsanwälte sind…). Diverse Informationen können tabellarisch oder im json-Format abgehandelt werden. Das macht die Sache kurz und sehr deutlich. Wir verwenden für das Verarbeitungsverzeichnis grundsätzlich json. Das Format lässt sich im Browser strukturiert und übersichtlich darstellen und man kann einfache Strukturen ebenso wie geschachtelte Strukturen sehr flexibel, aber gleich strukturiert, handhaben.
Entscheidend in der DSFA sind eine saubere und begründbare Risikoanalyse/Bewertung und die daraus folgenden Maßnahmen - entweder als Vorgabe für Softwareauswahlkriterien und/oder für die Handhabung im Betrieb.
Sowohl als auch. Im Browser lassen sich json-Dateien strukturiert darstellen und z.B. mit bluefish unter Linux einfach editieren. Die eigene Darstellung mit der Möglichkeit, zu einer fertigen Struktur (Vorgaben für TOM, Verarbeitungsverfahren und Organisationsstruktur/Verantwortliche des Mitglieds) eine Substruktur hinzuzufügen, wird gerade in unsere interne Anwendung eingebaut. Über den Mitgliederbereich kann sich jedes Mitglied über den aktuellen Stand seiner Dokumentation informieren. Für die DSFA fügen wir nur die Links auf die jeweilige json-Doku als Referenz ein, die dann aufgerufen oder als Anahng ausgedruckt werden kann.
Ach ja, dieses Vorgehen bei der Dokumentation vereinfacht das Leben für unsere Mitarbeiter als aktiver Erfasser wie als prüfender DSB ungemein, weil unnötiger Individualtext wegfällt und die Strukturen gleichartig und verständlich sind.
Das hier vorgestellte pia-tool der CNIL (Frankreich) ist mein persönlicher Favorit. Die Struktur ist immer gleich und verspricht so Übersichtlichkeit und gute Handhabbarkeit. Man wird gezwungen, sich wirklich Gedanken über sinnvolle TOM zu machen.
Inzwischen wurde der DSFA-Werkzeugkasten inkl. diverser Beispiele zur Datenschutz-Folgenabschätzung und der allgemeinen datenschutzrechtlichen Risikoanalyse des BayLfD weiterentwickelt und deutlich ausgebaut.
In der Frage der Erstellung einer DSFA habe ich über ein Buch zum Thema SDM einen Link zum Frauenhofer ISI gefunden. Der Titel ist: Die Datenschutz-Folgenabschätzung nach Art. 35 DSGVO - Ein Handbuch für die Praxis; Format: .pdf. Es beinhatet beinhaltet nicht nur Analyse von Datenfüssen sondern auch Teamarbeit bei der Ermittlung und Bewertung von Szenaien. Hier finde ich es schön, das mehrere Menschen des Unternehmens zusammenarbeiten können. anhand der Kapitel erhält nan eine schöne Form. In einem Gedankenspiel, Unternehmen mit 5 Mitarbeitern im Gesundheitsbereich, kam ich insgesamt auf 30 seiten.
]
