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 die Ihre technisch-organisatorischen Maßnahmen ausdrücklich einfließen.

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" zu berücksichtigen. Eine Komponente, die seit Jahren keine Sicherheitsupdates erhält oder deren Upstream verwaist ist, hält diesen Maßstab nicht von allein: Entweder Sie übernehmen die Pflege, oder Sie ersetzen sie.
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 bleiben. Ein Maintainer, der verschwindet, nimmt genau diese Dauerhaftigkeit mit. Die 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. Sicherungen, Ersatzsysteme und Wiederanlaufverfahren bringen Sie zurück in den Betrieb. Sicher weiterarbeiten können Sie erst, wenn jemand die ausgenutzte Lücke schließt - und dafür braucht es jemanden, der die Komponente patchen kann.
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. Den Verstoß muss die Aufsichtsbehörde belegen - Ihre Sorgfalt müssen Sie belegen. Ohne Dokumentation stehen Sie im Verfahren ohne Verteidigungslinie.

Warum das alte Software besonders trifft #

Veraltete oder ungepflegte Software ist im Betriebsalltag verbreitet - und sie gehört zu den verlässlichsten Wegen in eine Datenschutzverletzung mit Bußgeldfolge. Die Aufsichtsbehörden beanstanden dabei selten nur einen Punkt: Neben fehlenden Sicherheitsupdates und lückenhaftem Schwachstellenmanagement stehen regelmäßig unzureichende Zugangssicherung, fehlende Angriffserkennung oder versäumte Löschverfahren in den Bescheiden. Die folgenden fünf Fälle zeigen, wie unterschiedlich diese Versäumnisse aussehen - und wie teuer sie werden.

Advanced Computer Software Group, 2025 (ICO, 3,1 Mio. GBP). Der Ransomware-Angriff begann über ein Kundenkonto ohne Mehrfaktor-Anmeldung. Zur Ausweitung der Rechte wurde wahrscheinlich die seit rund zwei Jahren bekannte Zerologon-Schwachstelle (CVSS 10.0) genutzt, für die 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, je nach Produkt 18 bis 284 Tage Nichtverfügbarkeit für Kunden. ICO-Entscheidung.
Dedalus Biologie, 2022 (CNIL, 1,5 Mio. Euro). Ein Medizinsoftware- Anbieter schützte Gesundheitsdaten von rund 500 000 Menschen unzureichend, 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, hier u. a. nach Art. 28 Abs. 3. CNIL-Entscheidung.
British Airways, 2020 (ICO, 20 Mio. GBP). Angreifer schleusten nach dem Eindringen über einen Fernzugang Schadcode in eine JavaScript-Datei ein. Personendaten von mehr als 400 000 Menschen waren betroffen. Die Aufsicht stellte einen Verstoß gegen Art. 5 Abs. 1 lit. f und Art. 32 fest: Unter anderem waren Zugangssicherung und Angriffserkennung unzureichend. ICO-Entscheidung.
Deutsche Wohnen SE, 2019 (Berliner Beauftragte, 14,5 Mio. Euro). Die IT-Systeme wurden nicht rechtzeitig für die fristgerechte Löschung personenbezogener Daten angepasst. Das Landgericht Berlin I setzte die Geldbuße am 9. Juni 2026 auf 900 000 Euro fest; bei Bekanntgabe war das Urteil noch nicht rechtskräftig. Gerichtsmitteilung.
Morele.net, 2024 (polnische UODO, über 3,8 Mio. PLN). Nach Aufhebung des Bescheids von 2019 verhängte die Behörde erneut ein Bußgeld. Beanstandet wurden u. a. fehlende Zwei-Faktor-Anmeldung und unzureichende Überwachung. UODO-Mitteilung.

Das gemeinsame Muster: Die technischen und organisatorischen Schutzmaßnahmen reichten nicht aus, und niemand im Haus hatte den vollständigen Überblick über den eigenen Softwarebestand. Patch- und Schwachstellenmanagement ist der Teil dieses Risikos, der sich systematisch schließen lässt - und genau diese Aufgabe übernimmt OTTRIA für Ihre Open-Source-Abhängigkeiten.

Dokumentierte Sorgfalt wirkt auf die Bußgeldhöhe #

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, bringt entlastende Umstände in die Bemessung ein. Wer nichts vorlegt, verschenkt diesen Spielraum - und zwar in einem Rahmen 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.

Die 72-Stunden-Meldepflicht entscheidet sich an Ihrer SBOM #

Art. 33 Abs. 1 verlangt die Meldung einer Schutzverletzung unverzüglich und möglichst binnen 72 Stunden nach Kenntnis, sofern ein Risiko für Betroffene nicht voraussichtlich ausgeschlossen ist. 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. Eine SBOM verlangt Art. 33 dafür nicht. In der Praxis entscheidet sie aber darüber, ob Sie betroffene Komponenten, Datenkategorien und laufende Maßnahmen binnen Stunden zuordnen können oder ob Sie nach Art. 33 Abs. 4 wochenlang nachreichen.

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 erfasste Softwareprodukte: eine SBOM mindestens der obersten Abhängigkeiten und grundsätzlich mindestens fünf Jahre Sicherheits-Support. Was der Gesetzgeber dort ausdrücklich verlangt, prägt die Erwartung an angemessene Sicherheit auch im DSGVO-Verfahren.
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 erfasst die Zerstörung oder Beschädigung nicht beruflich verwendeter Daten. 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 keine Kür neben der DSGVO-Compliance, sondern ihr technischer Unterbau. Eine gepflegte SBOM, eine nachvollziehbare Maßnahmenhistorie und belegbare Sorgfalt bei der Komponentenauswahl sind das, was Sie einer Aufsichtsbehörde zu Art. 32 tatsächlich vorlegen können.

Gesetzesreferenzen #

Die wichtigsten Artikel der DSGVO für diesen Kontext:

Art. 5 Abs. 1 lit. f: Integrität und Vertraulichkeit
Art. 5 Abs. 2: Rechenschaftspflicht
Art. 25 Abs. 1: Datenschutz durch Technikgestaltung, Stand der Technik
Art. 28 Abs. 1: Hinreichende Garantien durch Auftragsverarbeiter
Art. 32 Abs. 1: Sicherheit der Verarbeitung, "auf Dauer", regelmäßige Überprüfung
Art. 33 Abs. 1: 72-Stunden-Meldefrist
Art. 83 Abs. 2 lit. d: Art. 25/32-Maßnahmen als Faktor der Bußgeldbemessung
Art. 83 Abs. 4: Bußgeldrahmen bis 10 Mio. Euro / 2 %
Art. 83 Abs. 5: Bußgeldrahmen bis 20 Mio. Euro / 4 %

Weiterlesen #

DSGVO-Factsheet herunterladen: (in Erstellung)

Sie möchten Ihre Open-Source-Governance im Licht der DSGVO bewerten lassen? Sprechen Sie mit uns.