deenx-default

DSGVO: Stand der Technik, dauerhaft und nachweisbar

Die DSGVO ist das am längsten geltende der hier behandelten EU-Gesetze - und in vielen Unternehmen das am schlechtesten technisch untermauerte. Der Grund ist naheliegend: Einwilligungen, Verzeichnisse, Auskunftsrechte und Datenschutzbeauftragte stehen seit Jahren auf Checklisten. Die technisch-organisatorischen Maßnahmen nach Art. 32 dagegen werden häufig einmal beschrieben und dann kaum aktualisiert. Genau dort beginnt das Haftungsrisiko.

Wer ist betroffen? #

Jedes Unternehmen, das personenbezogene Daten verarbeitet - von Mitarbeiter­ daten über Kunden- und Lieferantendaten bis zu Logdaten - ist Verantwortlicher im Sinne der DSGVO. Die Pflichten aus Art. 5, 25, 32 und 33 gelten unabhängig von Branche und Unternehmensgröße. Wer im Auftrag verarbeitet - MSPs, SaaS-, Cloud- und Hosting-Anbieter, Agenturen, Systemhäuser - haftet zusätzlich als Auftragsverarbeiter nach Art. 28 und muss gegenüber Kunden "hinreichende Garantien" für geeignete technische und organisatorische Maßnahmen bieten.

Die drei technischen Kernforderungen #

Stand der Technik #

Art. 25 Abs. 1 und Art. 32 Abs. 1 verlangen beide "den Stand der Technik". Der Begriff ist bewusst dynamisch: Was heute Stand der Technik ist, ist es in 18 Monaten nicht mehr. Eine Komponente ohne laufende Pflege fällt früher oder später aus diesem Maßstab heraus - und zwar ohne äußeres Ereignis, allein durch Zeitablauf.

Dauerhafte Belastbarkeit #

Art. 32 Abs. 1 lit. b verlangt, dass Vertraulichkeit, Integrität, Verfügbarkeit und Belastbarkeit "auf Dauer" sichergestellt werden. Diese zwei Wörter sind der entscheidende Unterschied zwischen einer Bestandsaufnahme und einer laufenden Verpflichtung. Eine verwaiste Open-Source-Bibliothek, deren Upstream verschwunden ist oder deren Maintainer nicht mehr reagiert, bricht diese Garantie, ohne dass der Verantwortliche dies sofort bemerkt.

Regelmäßige Überprüfung und Dokumentation #

Art. 32 Abs. 1 lit. d fordert ein Verfahren zur regelmäßigen Überprüfung, Bewertung und Evaluierung der Wirksamkeit der Maßnahmen. Art. 5 Abs. 2 verlangt zusätzlich, dass der Verantwortliche die Einhaltung aller Grundsätze nachweisen kann. Zusammen ergibt das eine faktische Dokumentationspflicht: Ohne Nachweis ist der Einwand einer "angemessenen Sicherheit" im Verfahren wertlos.

Was ändert sich durch das Zusammenspiel mit CRA, NIS2 und Produkthaftung #

Die DSGVO steht nicht mehr allein. Der Cyber Resilience Act konkretisiert den Stand der Technik für Softwareprodukte und macht SBOM und fünf Jahre Sicherheitsupdates zur gesetzlichen Pflicht. Die NIS2-Richtlinie verpflichtet kritische Sektoren zu Lieferkettensicherheit. Die neue Produkthaftungsrichtlinie nennt Datenverlust ausdrücklich als Haftungsgrund.

Für DSGVO-Verfahren hat das zwei Folgen:

Konsequenzen #

Bußgeldrisiko bis 4 % des Jahresumsatzes #

Art. 83 Abs. 5 sieht bei Verstößen gegen die Grundsätze aus Art. 5 Bußgelder von bis zu 20 Mio. Euro oder 4 % des weltweiten Jahresumsatzes vor - je nachdem, welcher Betrag höher ist. Bei Verstößen gegen Art. 25 bis 39 (also auch Art. 32) gilt der Rahmen von bis zu 10 Mio. Euro oder 2 % nach Art. 83 Abs. 4. In beiden Fällen gilt die gesamte Unternehmensgruppe als Bemessungsgrundlage. Innerhalb dieses Rahmens nennt Art. 83 Abs. 2 lit. d die nach Art. 25 und 32 getroffenen technischen und organisatorischen Maßnahmen ausdrücklich als Abwägungsfaktor: Wer sie belegen kann, zahlt im Einzelfall weniger.

72-Stunden-Meldefrist braucht einen SBOM-Stand #

Art. 33 Abs. 1 setzt die Frist, Art. 33 Abs. 3 definiert den Inhalt: Kategorien und ungefähre Zahl der betroffenen Datensätze, wahrscheinliche Folgen, ergriffene Maßnahmen. Wer seine Software-Bestandteile nicht kennt, kann binnen 72 Stunden keinen belastbaren Bericht liefern - und handelt sich damit einen zusätzlichen Verstoß gegen die Meldepflicht ein.

Faktische Beweislastumkehr #

Die Rechenschaftspflicht aus Art. 5 Abs. 2 kehrt die Beweisrichtung faktisch um: Wer die Einhaltung der Grundsätze nicht nachweisen kann, wird im Verfahren behandelt, als habe er sie nicht eingehalten. Das deckt sich mit der Struktur der Produkthaftung - und macht die Dokumentation zum wichtigsten einzelnen Verteidigungsinstrument.

EOL- und Löschschutz für die gesamte Lieferkette #

Die sichtbaren Komponenten einer Anwendung sind nur die Spitze. Unter jedem Produkt, das Sie einsetzen - egal ob Shop-System, ERP, CRM, Reporting-Tool, Messaging-Plattform oder intern entwickelte Anwendung - liegt eine Abhängigkeitskette, die sich unabhängig von Ihnen verändert und die das Risiko trägt.

Wer ein Produkt betreibt, denkt an das Produkt. Die tatsächlich ausgeführte Software ist aber das Produkt plus seine direkten Abhängigkeiten plus deren eigene Abhängigkeiten - eine Lieferkette mit hunderten Knoten, unabhängig davon, ob sie in einer `package.json`, `requirements.txt`, `go.mod`, `pom.xml`, `Cargo.toml`, `composer.json`, `Gemfile` oder in den Paketen einer Linux-Distribution dokumentiert ist. Zum Zeitpunkt der Inbetriebnahme war jede dieser Bibliotheken aktiv und fehlerfrei. Einige Zeit später kann mehreres davon geschehen sein, ohne dass es jemand bemerkt:

Keine dieser Veränderungen löst bei Ihnen einen automatischen Alarm aus. Kein Scanner meldet sie, weil es kein CVE gibt. Für die DSGVO sind sie trotzdem unmittelbar relevant: Sie brechen die Garantie nach Art. 32 Abs. 1 lit. b auf dauerhafte Belastbarkeit der Systeme, und sie machen die Wiederherstellbarkeit nach lit. c illusorisch - wenn niemand mehr patcht, gibt es nichts wiederherzustellen.

Open-Source-Projekte haben keine Pflicht, ihre Software zu pflegen oder verfügbar zu halten. Die gesetzliche Pflicht zur dauerhaften Belastbarkeit liegt aber bei Ihnen als Verantwortlichem. Diese Lücke schließt OTTRIA: Wir überwachen die gesamte Abhängigkeitskette auf Archivierung, Löschung, EOL und faktische Verwaisung - und übernehmen im Bedarfsfall selbst die Wartung oder stellen Patches bereit, damit Ihre Lieferkette weiterfunktioniert, auch wenn der Upstream nicht mehr existiert.

Was OTTRIA übernimmt #

HaftungsrisikoOTTRIA-Leistung
Unterschreitung des Stands der TechnikLaufende Bewertung eingesetzter OSS-Komponenten einschließlich transitiver Abhängigkeiten
Verletzung der "auf Dauer"-Verfügbarkeit (Art. 32 lit. b)Monitoring kritischer Abhängigkeiten auf Verwaisung, EOL-Ankündigung, Archivierung, Löschung durch den Upstream
Verwaiste, gelöschte oder EOL-gesetzte AbhängigkeitenWartungsübernahme oder Bereitstellung von Patches für unmaintained Projekte, koordiniert über unser Netzwerk
Fehlende regelmäßige Überprüfung (Art. 32 lit. d)Dokumentierte Evaluierungszyklen mit Maßnahmenhistorie je Komponente
Rechenschaftspflicht nach Art. 5 Abs. 2Prüffähige OSS-Governance-Dokumentation als Nachweis der Sorgfalt
72-Stunden-Meldefrist nach Art. 33Aktuelle SBOM mit Pflegestatus, Zuordnung von Schwachstellen zu betroffenen Datenkategorien
Auftragsverarbeiter-Garantien nach Art. 28Belastbare Nachweise für TOM, die MSPs gegenüber ihren Kunden vorlegen können
Unbekannte transitive AbhängigkeitenSBOM-Auswertung und -Überwachung über die gesamte Lieferkette, nicht nur über die direkten Abhängigkeiten

Was OTTRIA nicht übernimmt #

Was legen Sie der Aufsichtsbehörde vor? #

Im Bußgeldverfahren entscheidet die Dokumentation. Je belastbarer Sie den Stand der Technik, die laufende Pflege und die getroffenen Maßnahmen belegen können, desto niedriger fällt die Bußgeldbemessung nach Art. 83 Abs. 2 lit. d aus.

OTTRIA liefert Ihnen #

Sie ergänzen #

Hinweise zur deutschen Aufsichtspraxis #

Die deutschen Landesdatenschutzbehörden und der BfDI haben in den vergangenen Jahren mehrfach Bußgelder verhängt, die ausdrücklich auf einen Verstoß gegen Art. 32 gestützt wurden. Die Begründungen ähneln sich: Der Verantwortliche konnte nicht nachweisen, dass er die eingesetzten Komponenten auf dem Stand der Technik hielt, Sicherheitsupdates zeitnah einspielte oder Schwachstellen systematisch nachverfolgte. Bei der Bemessung wird regelmäßig auf das Fehlen dokumentierter Verfahren abgestellt.

Dokumentierte Sorgfalt ist keine Zierde - sie ist der einzige Hebel, mit dem sich das Bußgeld im Verfahren nachweisbar senken lässt.

Erstgespräch vereinbaren

DSGVO-Factsheet herunterladen (in Erstellung)

Weiterlesen #