Projektmanagement unter den Anforderungen des Datenschutzes

Das zukünftige Datenschutzgesetz der Schweiz und die DSGVO verlangen, dass der Datenschutz in Projekten bereits ab der Planungsphase berücksichtigt wird. Wer dies bereits beachtet unterstützt eine möglichst positive Nutzererfahrung und umgeht negative Folgen für das Projekt und das Unternehmen.

Im Allgemeinen kann Datenschutz auf drei verschiedene Wege eingeführt werden: Bottom-up, middle-out oder top-down. Meine Empfehlung ist es, wenn immer möglich den Bottom-up-Ansatz zu wählen. Für Verantwortliche bedeutet dies, dass sie Datenschutz bei der Konzeption eines Service (beispielsweise einer Webseite oder eines Prozesses) als Rahmenbedingung betrachen. Wird Datenschutz im Projektverlauf nicht, ungenügend oder zu spät berücksichtigt, kann dies zu negativen Folgen (siehe folgende Abschnitte) für den Projektverlauf, das Endresultat des Projektes und/oder das Unternehmen direkt führen.

Je nach Situation muss Datenschutz bottom-up, middle-out oder top-down eingeführt werden. (Bild: Beda Kohler)

Bottom-up: Datenschutz als Muss-Ziel im Projektauftrag

Um möglichen Konsequenzen wegen Nichteinhalten des Datenschutzes entgegenzuwirken, wird die Einhaltung dessen bereits im Projektauftrag als Muss-Ziel definiert. Der Requirements Engineer leitet daraus die notwendigen Anforderungen des Datenschutzes an das Projektergebnis ab. Damit die gesammelten Anforderungen den Gesetzen genügen, empfehle ich eine Fachperson (z.B. der betriebliche Datenschutzberater) zur Definition der Anforderungen und zum späteren Review des Lastenhefts beizuziehen.

Für den Projekterfolg entscheidend: Die Techniker mit den Juristinnen zusammenbringen, eine gemeinsame Sprache entwickeln und die Weichen gemeinsam stellen. Sind die Anforderungen eindeutig formuliert, weiss die Technik wo die Grenzen liegen und kann das darin mögliche Maximum an User Experience umsetzen. Gleichzeitig arbeiten wir mit diesem Vorgehen dem Grundsatz «Privacy by Design» (Art. 25 Abs. 1 DSGVO) bzw. «Datenschutz durch Technik» (Art. 6 Abs. 1 E-DSG, Seite 17) zu, der unter anderem verlangt, dass Datenschutz in der Gestaltung von Services durch die Konzeption gegeben ist. Dadurch ermöglichen wir zudem die Einhaltung des Prinzips «Privacy by Default» (Art. 25 Abs. 2 DSGVO) bzw. «Datenschutz durch datenschutz-freundliche Voreinstellungen» (Art. 6 Abs. 3 E-DSG, Seite 17), das Voreinstellungen zugunsten des Schwächeren verlangt.

Das richtige Mass ist entscheidend

Cookie-Banner und Datenschutz-Meldungen: Sind sie in manchen Fällen in der vorliegenden Form notwendig, um den geltenden Gesetzen gerecht zu werden, schiessen Sie in anderen Fällen über das Ziel hinaus. Ich halte die These, dass in so manchem Fall das Maximum an möglichem Datenschutz implementiert wurde, ohne zu analysieren, wie viel überhaupt notwendig ist. Verantwortlichen möchte ich nahelegen nach dem Minimalprinzip abzuwägen, welche Daten denn überhaupt gesammelt werden müssen. Bietet das Sammeln der Daten für den Nutzer oder den Anbieter des Service wirklich einen Mehrwert? Aus der Beantwortung dieser Frage kann ein grosses Optimierungspotential in der Gestaltung der Meldung resultieren, sofern das betroffene Angebot nicht gar ohne zurechtkommt.

Middle-out: Korrektur

Bemerkt die Projektleiterin während der Umsetzungsphase, dass die Rahmenbedingungen nicht oder unzureichend definiert wurden oder ändern sich diese während des Projekts, kann er das Pflichtenheft entsprechend anpassen. In diesem Fall zeigt sich das aus dem Projektmanagement bekannte «Magische Dreieck» in den möglichen Folgen deutlich:

  • Das Projekt gerät in Verzug, da zur nachträglichen Umsetzung der neuen Anforderungen keine zusätzlichen Ressourcen zur Verfügung stehen.
  • Die Umsetzung kostet mehr Ressourcen, da die Qualität- & Leistungsziele eingehalten werden müssen.
  • Das Ergebnis erfüllt die Qualität- & Leistungsziele nicht, da dem Projekt für die nachträglichen Änderungen nicht genügend Zeit zur Verfügung steht.

Bleiben der Mangel über die Projektdauer hinaus unbemerkt, geraten zwar das Projektbudget, die Ressourcen und die Qualität nicht zusätzlich unter Druck. Die Folgen zeigen sich aber möglicherweise später:

  • Negaive Folgen für Betroffene, da Daten durch Unberechtigte bearbeitet werden können
  • Bussen wegen Nichteinhaltung der Datenschutzgesetze
  • Reputationsschäden durch allfällige Medienberichte
  • Kostspielige nachträgliche Korrekturen

Entscheidet sich die verantwortliche Person für eine nachträgliche Anpassung, entspricht dies dem Top-down-Ansatz.

Top-down: Anpassungen durch Nachprojekt

Nachträgliche Anpassungen können im Rahmen eines Nachprojekts durchgeführt werden. Dabei sind insbesondere folgende Faktoren kritisch:

  • Nachträgliche Korrekturen können tief greifen und daher kostspielig sein.
  • Mögliche Einschnitte bei der Bedienbarkeit eines Produkts oder in der Durchführung von Arbeitsabläufen bedingen Ressourcen, um die nachträgliche Veränderung entsprechend zu begleiten. Die enge Zusammenarbeit zwischen Juristen und der Technikerinnen ist, um ein möglichst benutzerfreundliches Ergebnis zu erzielen (siehe auch «Bottom-up-Ansatz»), auch hier unabdingbar.

Besonders der Top-down-Ansatz «Anpassungen durch Nachprojekt» wird spätestens mit der Einführung des neuen Datenschutzgesetzes in der Schweiz an Wichtigkeit gewinnen, da wohl viele bestehende Systeme angepasst werden müssen. Dabei rate ich jeweils zu evaluieren, ob in diese Top-down-Anpassungen investiert werden soll oder ob sich allenfalls der Bottom-up Weg im Rahmen einer Ablösung lohnt.

Beitrag teilen

Beda Kohler

Beda Kohler ist IT Projektleiter im Bereich Applikationen bei der Stiftung Brändi und bloggt aus dem Unterricht des CAS Data Privacy Officer.

Alle Beiträge ansehen von Beda Kohler →

Schreibe einen Kommentar