Die DSGVO und Open-Source-Governance
Die Datenschutz-Grundverordnung ist seit 2018 unmittelbar geltendes Recht. In
der öffentlichen Wahrnehmung geht es dabei meist um Einwilligungen,
Datenschutzerklärungen und Auskunftsrechte. Die technisch-organisatorischen
Pflichten der DSGVO sind aber mindestens ebenso hart - und sie treffen jede
Software, die personenbezogene Daten verarbeitet, also praktisch jede
betriebliche Anwendung.
Für Open-Source-Governance sind vier Punkte zentral: der "Stand der Technik",
die Pflicht zur dauerhaften Sicherstellung von Integrität und Verfügbarkeit,
die Rechenschaftspflicht und die Bußgeldbemessung, in der dokumentierte
technisch-organisatorische Maßnahmen ausdrücklich als mildernder Faktor zählen.
Was die DSGVO technisch fordert
- Stand der Technik (Art. 25 Abs. 1, Art. 32 Abs. 1). Sowohl bei der Auswahl der Verarbeitungsmittel als auch bei der fortlaufenden Sicherheit verlangt die DSGVO den "Stand der Technik". Eine Komponente, die seit Jahren keine Sicherheitsupdates erhält oder deren Upstream verwaist ist, unterschreitet diesen Maßstab per Definition.
- Integrität und Verfügbarkeit "auf Dauer" (Art. 32 Abs. 1 lit. b). Der Wortlaut ist eindeutig: Systeme müssen "auf Dauer" vertraulich, integer, verfügbar und belastbar sein. Ein Maintainer, der verschwindet, bricht genau diese Garantie. Eine einmalige Auswahl einer Komponente ist kein Nachweis dauerhafter Sicherheit.
- Wiederherstellbarkeit nach Zwischenfall (Art. 32 Abs. 1 lit. c). Der Verantwortliche muss in der Lage sein, die Verfügbarkeit der Daten nach einem Zwischenfall "rasch" wiederherzustellen. Das setzt voraus, dass jemand die betroffene Komponente patchen kann - und zwar sofort, nicht wenn irgendwann ein Maintainer reagiert.
- Regelmäßige Überprüfung der Wirksamkeit (Art. 32 Abs. 1 lit. d). Die DSGVO verlangt ein "Verfahren zur regelmäßigen Überprüfung, Bewertung und Evaluierung" der Maßnahmen. Ein Scan einmal im Quartal ist keine Evaluierung - er ist eine Bestandsaufnahme. Die Wirksamkeit einer Maßnahme lässt sich nur beurteilen, wenn dokumentiert ist, wie auf erkannte Risiken reagiert wurde.
- Rechenschaftspflicht (Art. 5 Abs. 2). Der Verantwortliche muss die Einhaltung der Grundsätze nachweisen können. Das kehrt die Beweislast faktisch um: Ohne Dokumentation steht man im Verfahren vor der Aufsichtsbehörde ohne Verteidigungslinie.
Warum das alte Software besonders trifft
Veraltete oder ungepflegte Software ist im Betriebsalltag verbreitet - und
sie ist der häufigste Ausgangspunkt für Datenschutzverletzungen mit
Bußgeldfolge. Die Aufsichtsbehörden begründen ihre Entscheidungen
regelmäßig damit, dass einschlägige Sicherheitsupdates nicht eingespielt,
bekannte Schwachstellen nicht behoben oder veraltete Komponenten weiter
produktiv betrieben wurden.
- Advanced Computer Software Group, 2025 (ICO, 3,1 Mio. GBP). Erstes Processor-Bußgeld unter UK GDPR. Ransomware-Angriff über eine seit rund zwei Jahren ungepatchte kritische Schwachstelle (CVSS 10.0), obwohl ein Patch verfügbar war. Die ICO rügte ausdrücklich "ad hoc patch management" und unzureichendes Schwachstellenscanning als Verstoß gegen Art. 32. 79 404 Betroffene, NHS 111 gestört, rund 300 Tage bis zur vollständigen Wiederherstellung.
- Dedalus Biologie, 2022 (CNIL, 1,5 Mio. Euro). Ein Medizinsoftware- Anbieter verlor rund 500 000 Gesundheitsdatensätze durch unzureichende Sicherheitsmaßnahmen, u. a. während einer Datenmigration. Die CNIL stützte das Bußgeld auf Art. 28, 29 und 32 DSGVO - ein Lehrstück für die Haftung von Auftragsverarbeitern nach Art. 28 Abs. 1.
- British Airways, 2020 (ICO, 20 Mio. GBP). Angreifer schleusten Schadcode über eine manipulierte JavaScript-Bibliothek ein (Magecart). Personendaten von rund 400 000 Kunden wurden abgegriffen. Die Aufsicht stellte einen Verstoß gegen Art. 5 Abs. 1 lit. f und Art. 32 fest: Der Einsatz und die Überwachung der Komponente waren nicht auf dem Stand der Technik.
- Deutsche Wohnen SE, 2019 (Berliner Beauftragte, 14,5 Mio. Euro). Eine veraltete Archivierungssoftware erlaubte die weitere Speicherung personenbezogener Daten ohne Löschmöglichkeit. Die Aufsicht wertete das als Verstoß gegen Art. 5 und Art. 25.
- Morele.net, 2019 (polnische UODO, 2,8 Mio. PLN). Der Online-Händler hatte eine ungepatchte Schwachstelle über Monate nicht behoben. Die Aufsicht sah einen Verstoß gegen Art. 32 als gegeben an.
Das Muster ist überall gleich: Die Schwachstelle war bekannt, der Fix war
verfügbar, die Organisation hatte weder den Überblick noch die Kapazität,
den Fix rechtzeitig einzuspielen. Genau an dieser Stelle greift
Open-Source-Governance - und genau diese Lücke schließt OTTRIA.
Bußgelder werden durch dokumentierte Sorgfalt gemindert
Art. 83 Abs. 2 lit. d nennt den "Grad der
Verantwortung des Verantwortlichen [...] unter Berücksichtigung der von ihnen
gemäß den Artikeln 25 und 32 getroffenen technischen und organisatorischen
Maßnahmen" ausdrücklich als bußgeldrelevanten Faktor. Übersetzt: Wer
nachweisen kann, dass er systematisch, dokumentiert und nach dem Stand der
Technik gearbeitet hat, zahlt weniger. Wer keinen Nachweis liefert, zahlt
das volle Bußgeld - bis zu 10 Mio. Euro bzw. 2 % des weltweiten Jahresumsatzes
nach Art. 83 Abs. 4,
bei Verstößen gegen die Grundsätze aus Art. 5 sogar bis zu 20 Mio. Euro bzw.
4 % nach Art. 83 Abs. 5.
72-Stunden-Meldepflicht braucht eine SBOM
Art. 33 Abs. 1 verlangt die Meldung einer
Schutzverletzung binnen 72 Stunden nach Kenntnis. Art. 33 Abs. 3
präzisiert, welche Informationen die Meldung enthalten muss: Kategorien und
ungefähre Zahl der betroffenen Datensätze, wahrscheinliche Folgen, ergriffene
Gegenmaßnahmen. Diese Informationen setzen voraus, dass der Verantwortliche
binnen Stunden feststellen kann, welche Komponente betroffen ist, welche
Datenkategorien sie berührt und welche Maßnahmen bereits laufen. Ohne eine
aktuelle, gepflegte SBOM ist diese Frist praktisch nicht einhaltbar.
Auftragsverarbeiter haften durchgängig
Art. 28 Abs. 1 erlaubt die Beauftragung nur mit
Auftragsverarbeitern, die "hinreichend Garantien" für geeignete technische
und organisatorische Maßnahmen bieten. Für MSPs, Cloud-Provider, SaaS-Anbieter
und Agenturen ist das ein unmittelbarer Vertriebsfaktor: Wer diese Garantien
nicht belegen kann, verliert Aufträge - und seine Kunden handeln rechtswidrig,
wenn sie ihn trotzdem beauftragen.
Zusammenspiel mit CRA, NIS2 und Produkthaftung
Die DSGVO steht nicht allein. Ihre Pflichten überschneiden sich systematisch
mit den jüngeren EU-Gesetzen:
- Der Cyber Resilience Act konkretisiert den "Stand der Technik" für Softwareprodukte und fordert eine vollständige SBOM sowie fünf Jahre Sicherheitsupdates - beides sind faktisch DSGVO-relevante Mindestanforderungen.
- NIS2 verpflichtet kritische Sektoren zu Lieferkettensicherheit. Ein Verstoß gegen Art. 21 NIS2 ist im Schadensfall zugleich ein starkes Indiz für einen Verstoß gegen Art. 32 DSGVO.
- Die neue Produkthaftung nennt Datenverlust ausdrücklich als Haftungsgrund. Derselbe Vorfall kann damit parallel zu einer DSGVO-Strafzahlung und zu einer Produkthaftungsforderung führen - zwei getrennte Rechtsfolgen aus einer Ursache.
Was das für Sie bedeutet
Wer personenbezogene Daten verarbeitet - und das tun praktisch alle
Unternehmen - ist für den Stand der Technik der eingesetzten Software
verantwortlich. Open-Source-Komponenten sind dabei kein Sonderfall, sondern
der Regelfall: Sie stecken in jeder betrieblichen Anwendung. Die DSGVO
verlangt nicht nur, dass diese Komponenten sicher sind, sondern dass ihre
Sicherheit auf Dauer gewährleistet und nachweisbar gepflegt wird.
Dokumentierte Open-Source-Governance ist damit nicht eine Kür neben der
DSGVO-Compliance, sondern ihr technischer Unterbau. Ohne gepflegte SBOM,
nachvollziehbare Maßnahmenhistorie und belegbare Sorgfalt bei der
Komponentenauswahl ist Art. 32 nicht erfüllbar.
Gesetzesreferenzen
Die wichtigsten Artikel der DSGVO für diesen Kontext:
Weiterlesen
DSGVO-Factsheet herunterladen: (in Erstellung)
Sie möchten Ihre Open-Source-Governance im Licht der DSGVO bewerten
lassen? Sprechen Sie mit uns.
