Aus der Erfahrung von fast 25 Jahren individueller Softwareprojekte kann ich sagen, dass dieses Thema von vielen Auftraggebern unterschätzt wird. Dabei gibt es in jeder Phase des Projekts Datenschutzrelevante Herausforderungen.

Es genügt nicht, eine Geheimhaltungsvereinbarung zu unterschreiben

Viele meinen, es sei mit einer schriftlichen Vereinbarung getan, in der sich der Software-Dienstleister verpflichtet, mit den Daten, die er vom Kunden erhält, ordentlich umzugehen. Hier werden oft seitenlange Standardverträge unterschrieben – und auf der Basis glaubt man dann, im Projekt alle möglichen Echtdaten verwenden zu können. Aber so einfach ist das nicht. Denn eine Vereinbarung zwischen Softwareentwickler und Auftraggeber erlaubt es beiden noch lange nicht, Daten von Kunden, Lieferanten und Mitarbeitern des Auftraggebers im Projekt zu verwenden. Außerdem ist es ohnehin besser, dass solche Daten gar nicht erst im Projekt auftauchen, als dass man sich darüber verständigt, aufpassen zu wollen, dass diese Daten nicht „in falsche Hände geraten können“.

Deshalb sollten sich Softwarehaus und Auftraggeber gleich zu Beginn des Projekts darüber verständigen, wie die notwendigen Informationen bereitgestellt werden können, ohne dass Echtdaten im Projekt verwendet werden. Das kostet Aufwand und der muss im Budget und im Zeitplan berücksichtigt werden – aber unterm Strich tut man das Richtige.

Genau genommen muss das Thema aber schon beachtet werden, bevor überhaupt ein Vertrag unterschrieben wird. Wenn der Kunde dem Lieferanten beschreiben will, was er überhaupt mit dem Projekt erreichen will, braucht er Beispiele: Dokumente, die gegenwärtig verwendet werden, Listen, die verarbeitet werden sollen, und so weiter. Überall sind Daten von Kunden und Mitarbeitern zu sehen. Oft werden diese Informationen dem (potentiellen) Vertragspartner schon im ersten Gespräch vorgelegt oder zum Zwecke des besseren Verständnisses des Themas übermittelt.

Jedem sollte klar sein, dass ein solcher Umgang mit Daten nicht in Ordnung sein kann, selbst wenn der potentielle Dienstleister zuvor eine Erklärung unterschrieben hat in der er sich verpflichtet, die übergebenen Daten geheim zu halten. Also muss schon vor Vertragsschluss ein gewisser Aufwand getrieben werden, Daten zu anonymisieren und unkenntlich zu machen.

Datenschutz während der Anforderungsanalyse und der Software-Spezifikation

Oft werden für die Anforderungsanalyse und die Softwarespezifikation realistische Beispieldaten gebraucht, sei es in Form von Dokumenten, die durch das System später erzeugt werden sollen, Screenshots von Systemen, die bereits mit den Daten arbeiten, oder Listen und Berichten, die die benötigten Daten enthalten. Es führt kein Weg daran vorbei: Diese Daten müssen anonymisiert werden. Das muss natürlich auf eine Weise geschehen, dass wichtige Informationen für die Softwarespezifikation nicht verloren gehen – und deshalb ist die Sache auch hin und wieder aufwändig. Nur selten wird der Aufwand, der hier getrieben werden muss, in das Zeit- und Kostenbudget dieser Projektphase eingeplant.

Natürlich kann ein professioneller Software-Dienstleister bei der Anonymisierung der Daten unterstützen. Wie werden Namen und Adressen unkenntlich gemacht, ohne dass die Information verschwindet, um was für Daten es sich handelt? Darin hat ein Softwarehaus natürlich Erfahrungen.

Test mit produktionsnahen Daten – Anonymisierung ist nötig

Dies umso mehr, als sich der Aufwand ja lohnt, denn für die Testphase des Projekts werden ohnehin produktionsnahe Daten gebraucht – also muss man Wege finden, Echtdaten zu anonymisieren. Ein Konzept zur Bereitstellung von Testdaten sollte ohnehin schon in der Spezifikationsphase entstehen. In dieses Konzept muss das Thema Anonymisierung und Pseudonomisierung mit einbezogen werden. Meistens lohnt es sich, dafür ein paar automatische Routinen zu schreiben, denn für die Tests werden Testdatensets mit unterschiedlichem Umfang und Ausprägungen benötigt.

Ob für die endgültigen Abnahmetests Echtdaten verwendet werden können, hängt vom Einzelfall ab – wie wird wo getestet, wer hat Zugriff auf die Ergebnisse, und wie wichtig ist die Erkennbarkeit von „echten Daten“ im Fachtest? Immer, wenn Testergebnisse an den Lieferanten übergeben werden, müssen diese aber anonymisiert sein – somit ist fraglich, ob es sinnvoll ist, mit Echtdaten zu arbeiten.

Ein weiterer Aspekt, der mit dem Datenschutz im Sinne der DSGVO wenig zu tun hat, ist der Schutz von Geschäftsgeheimnissen. Wer in Softwareprojekten, vor allem in Tests, mit anonymisierten oder pseudonomisierten Echtdaten arbeitet, muss sich darüber im Klaren sein, dass die Daten hinsichtlich der Geschäftsvorfälle immer noch „echt“ sind – Umsatzzahlen, Produktinformationen oder Geschäftsstrukturen lassen sich daraus immer noch ableiten. Natürlich sollten Kunde und Lieferant einander vertrauen, aber manchmal geraten solche Daten auch durch Unachtsamkeit in falsche Hände. Ein Bewusstsein für die Vertraulichkeit solcher Daten immer wieder zu schaffen, sollte selbstverständliche Aufgabe von Management und Projektleitung sein.

Der Beitrag Wie organisiert man Datenschutz im Softwareprojekt erschien zuerst auf INDAL Software-Spezialist.

Nach den Vorstellungen des klassischen Wasserfall-Modells müsste der Business Analyst das DV-Konzept abnehmen und die Realisierung müsste auf der Basis dieses abgenommenen DV-Konzeptes erfolgen. Das ist aber nur zum Teil richtig.

Richtig ist, dass der Business Analyst das DV-Konzept eingehend prüfen muss, er soll ermitteln, ob alle Anforderungen der Fachseite im DV-Konzept aufgenommen wurden und ob Richtlinien und Vorgaben berücksichtigt worden sind. Eine Abnahme aber würde bedeuten, dass der Business Analyst die Verantwortung dafür übernimmt, dass das DV-Konzept die Anforderungen der Fachseite erfüllt – und das ist nicht möglich. Dem Lieferanten würde sozusagen eine Zwischen-Entlastung erteilt ohne dass er sicherstellt, dass die Software den Anforderungen der Fachseite wirklich gerecht werden wird. Das aber ist nicht möglich.

Zum einen kann der Business Analyst im Allgemeinen die Spezifikationsdetails des DV-Konzeptes nicht einschätzen, da es sich dabei um Vorgaben an den Entwickler handelt, dessen technische Know How der Business Analyst nicht hat und nicht haben muss. Zum Anderen kann eine Spezifikation nicht getestet werden wie eine Software, und nur wenn das möglich wäre, wenn man durch einen Test, durch Ausprobieren könnte, ob die Spezifikation “funktioniert”, könnte man auf das technische Know How zur Prüfung des DV-Konzeptes verzichten.

Das heißt jedoch nicht, dass das DV-Konzept nicht abgenommen werden sollte. Die Abnahme soll prüfen, ob die Anforderungen berücksichtigt werden, ob nicht-funktionale und funktionale Anforderungen abgestimmt sind, ob Richtlinien eingehalten wurden. Die Abnahme stellt fest, dass keine Mängel gefunden wurden – nicht, dass keine Mängel vorhanden sind.

Werden im Software-Abnahmetest Fehler gefunden und stellt sich heraus, dass diese Fehler bereits im DV-Konzept vorhanden sind, so hat der Auftraggeber ein Nachbesserungsrecht sowohl auf das DV-Konzept als auch auf die Software. Optimal ist allerdings, wenn vereinbart wird, dass dies nur für Fehler gilt, die der Business Analyst bei der Abnahme des DV-Konzeptes nicht finden konnte.

Das klingt kompliziert – und ehrlich gesagt, das ist auch kompliziert. Wie ein solcher Vertrag ausgestaltet werden kann, hängt sehr stark vom konkreten Projekt ab. Letztlich ist natürlich das Vertrauensverhältnis zwischen den Partnern und die Bereitschaft zum pragmatischen Kompromis ausschlaggebend – aber das lässt sich im Vertrag nicht festschreiben.

Der Beitrag Spezifikationen abnehmen? erschien zuerst auf INDAL Software-Spezialist.