IT Compliance in der Praxis – Daten und Projekte in der B2B-Softwareentwicklung richtig isolieren und löschen

Da es bei Compliance um die Einhaltung von Vorgaben jeglicher Art geht, ist das Thema sehr vielfältig und individuell. Deswegen soll es in diesem Post um ein recht spezielles Thema gehen: Die Löschung von Daten bei Vertragsende. In der B2B-Softwareentwicklung ist es üblich, dass Verträge einen Passus über die Aushändigung oder Vernichtung sämtlicher mit dem Projekt in Verbindung stehender Unterlagen und Dokumente enthalten.

Daniel Huchthausen

IT Consultant

Für viele ist Compliance ein abstrakter Begriff, mit dem sich nur Führungskräfte herumschlagen müssen. Aber dem ist nicht so. Compliance geht jeden etwas an.

Was ist Compliance und wieso ist es ein wichtiges Thema?

Kurz gesagt ist Compliance die Einhaltung von Gesetzen, Regeln, Standards, Verträgen und moralischen Werten, die sowohl von außerhalb als auch von innerhalb eines Unternehmens kommen können. Das Tückische an Compliance ist, dass ein Verstoß nicht sofort auffallen muss. Sobald er aber erkannt wird, kann es schnell unangenehm werden. Compliance betrifft nicht nur die Unternehmensführung, sondern jeden Angestellten, da jeder wissentlich oder unwissentlich bei seinen Entscheidungen einen Verstoß begehen kann. Beispiele hierfür sind unter anderem eine Software nicht entsprechend ihrer Lizenzbedingungen zu verwenden oder gegen Datenschutzvorgaben zu verstoßen, indem Daten nicht korrekt gelöscht werden.

Spezialfall: Löschung oder Aushändigung von Daten

In der B2B-Softwareentwicklung ist es üblich, dass Verträge einen Passus über die Aushändigung oder Vernichtung sämtlicher mit dem Projekt in Verbindung stehender Unterlagen und Dokumente enthalten.

Vertragspassage

Auf den ersten Blick scheint das kein Problem zu sein. Doch wie so oft liegt der Teufel im Detail. Je nachdem, wie genau es mit dem Aufräumen am Projektende genommen wird, kann es sehr aufwändig werden, wirklich alle Informationen und Daten zu finden und zu entfernen.

Mangelhafte Isolierung von Projekten kann ein Compliance-Thema sein

Der oben genannte Passus bedeutet, dass zum Ende eines Projektes alle Systeme durchsucht werden müssten, um alle Daten mit Bezug auf das Projekt zu finden. Das reicht von offensichtlichen Daten wie z.B. Repositories, Artefakten, Wiki-Einträgen, Dokumenten wie Konzepten oder Dokumentationen hin zu wenig offensichtlichen Daten wie zum Beispiel Tickets im Issue Tracker oder in Sekundärsystemen gespeichertem Quellcode. Wie aufwändig diese Suche ist, hängt im Wesentlichen von zwei Faktoren ab:

Umfang und Laufzeit des Projektes
Isolierung der Daten von unterschiedlichen Projekten

Umfang und Laufzeit von Projekten

Je länger und je größer ein Projekt ist, desto mehr Daten sammeln sich an und desto größer ist die Wahrscheinlichkeit, dass einige abgelegte Daten in Vergessenheit geraten und das mehr und mehr Systeme benutzt werden. Dadurch muss der „Suchradius“ deutlich ausgeweitet werden. Das bedeutet wiederum, dass der Aufwand steigt.

Eine starke Streuung von Daten kann z.B. durch organisatorische Vorgaben zum Speichern von Daten reduziert werden. Solche Regeln lassen aber oft viel Spielraum und sind daher nur begrenzt hilfreich.

Isolierung von Projekten

Neben der Größe und Laufzeit eines Projektes, ist auch dessen Isolierung von anderen Projekten ein Einflussfaktor auf den Aufwand zur Identifizierung aller relevanter Daten. Hier ein einfaches Beispiel für unterschiedlich starke Isolierung von Projekten:

Geringe Isolierung: Die Daten von unterschiedlichen Projekten werden alle auf einem Netzlaufwerk abgelegt. Es gibt keine vorgeschriebene Ordnerstruktur.
Mittlere Isolierung: Alle Daten liegen auf dem gleichen Laufwerk, jedes Projekt hat jedoch einen eigenen Ordner.
Starke Isolierung: Die Daten von unterschiedlichen Projekten sind jeweils auf einem eigenen Netzlaufwerk mit separater Festplatte gespeichert.

Es ist schnell ersichtlich, wie viel einfacher es bei dem stark isolierten Projekt ist die Daten zu identifizieren. Wenn alle Daten eines Projektes auf einer eigenen Festplatte gespeichert sind, kann diese ganz einfach an den Kunden übergeben oder zerstört werden. Im Falle der mittleren Isolierung müssen lediglich ein paar Ordner kopiert oder entfernt werden. Was beim gering isolierten Fall notwendig ist, kann sich jeder selbst ausmalen.

Zusätzlich gilt es zu bedenken, dass in jedem für das Projekt benutzen System Daten vorhanden sein können. Dadurch wird relativ schnell klar, wieso auch schon kleine Unterschiede eine große Wirkung haben können.

Backups – eine ganz eigene Geschichte

Doch damit nicht genug. Um Datenverlust während eines Projektes zu verhindern, werden Backups von Systemen erstellt. Je nach Isolierungsgrad der Projekte kann dadurch der Aufwand am Projektende nochmal multipliziert werden. Denn auch hier gilt: je niedriger der Isolierungsgrad, desto aufwändiger ist die Suche. Wenn die Backups dann noch komprimiert oder verschlüsselt sind, wird die Aufgabe noch aufwändiger und weil das noch nicht genug ist, muss auch noch bedacht werden, dass mit jeder Änderung am Backup auch noch dessen Integrität gefährdet wird.

Eine eigene Infrastruktur für jedes Projekt

Die gute Nachricht ist, dass es auch sehr einfach sein kann seinen Vertrag einzuhalten: Mit dem Cloudogu EcoSystem kann für jedes Projekt eine komplett eigenständige Instanz verwendet werden. In dieser befinden sich dann alle Daten wie Repositories, Issues, Dokumentation, Artefakte usw. So ist es ein Leichtes, sämtliche Daten am Ende des Projekts zu löschen oder an den Auftraggeber zu übergeben. Auch die Backups sind einfach zu löschen, da auch diese nach Projekten getrennt erstellt werden.