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 Mitarbeiterdaten über Kunden- und Lieferantendaten bis zu Logdaten - muss die DSGVO beachten. Wer über Zweck und Mittel der Verarbeitung entscheidet, ist Verantwortlicher; für ihn gelten die Pflichten aus Art. 5, 25, 32 und 33 unabhängig von Branche und Unternehmensgröße. Wer im Auftrag verarbeitet - MSPs, SaaS-, Cloud- und Hosting-Anbieter, Agenturen, Systemhäuser - ist für diese Verarbeitung Auftragsverarbeiter und muss nach Art. 28 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" zu berücksichtigen. Der Maßstab ist bewusst dynamisch: Was heute genügt, genügt in 18 Monaten womöglich nicht mehr. Eine Komponente ohne laufende Pflege entfernt sich deshalb Monat für Monat weiter davon - ohne äußeres Ereignis, allein durch Zeitablauf. Entscheidend ist dabei nicht ihr Alter, sondern ob sie noch jemand absichert: Kommen Sicherheitskorrekturen, übernimmt jemand die Pflege, greifen andere wirksame Schutzmaßnahmen? Bleibt diese Frage offen, tragen Sie das Risiko.

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, gefährdet diese Belastbarkeit - ohne dass der Verantwortliche es sofort bemerkt. Für jede solche Komponente brauchen Sie einen Plan: weiterpflegen, ersetzen oder wirksam abschirmen.

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: Im Verfahren zählt nicht, dass Ihre Sicherheit angemessen war, sondern dass Sie es belegen können.

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

Die DSGVO steht nicht mehr allein. Der Cyber Resilience Act macht für erfasste Softwareprodukte eine SBOM und grundsätzlich mindestens fünf Jahre Sicherheits-Support zur gesetzlichen Pflicht. Die NIS2-Richtlinie verpflichtet kritische Sektoren zu Lieferkettensicherheit. Die neue Produkthaftungsrichtlinie erfasst die Zerstörung oder Beschädigung nicht beruflich verwendeter Daten.

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. Wirksame, belegte Maßnahmen wirken damit unmittelbar auf die Höhe. Einen festen Rabatt gibt es dafür nicht. Aber es macht im Verfahren einen erheblichen Unterschied, ob Sie Ihre Verfahren beschreiben oder vorlegen können.

72-Stunden-Meldefrist: Ohne SBOM verlieren Sie die erste Woche #

Art. 33 Abs. 1 verlangt eine unverzügliche Meldung, möglichst binnen 72 Stunden nach Bekanntwerden - außer wenn voraussichtlich kein Risiko für die Rechte und Freiheiten Betroffener besteht. Art. 33 Abs. 3 definiert den Inhalt: Kategorien und ungefähre Zahl der betroffenen Datensätze, wahrscheinliche Folgen, ergriffene Maßnahmen. Eine SBOM schreibt das Gesetz dafür nicht vor. Die Frist läuft trotzdem. Wer bei einem softwarebedingten Vorfall erst herausfinden muss, welche Komponenten überhaupt im Einsatz sind, meldet unvollständig und reicht nach Art. 33 Abs. 4 wochenlang nach. Wer seine Stückliste kennt, grenzt den Vorfall am ersten Tag ein.

Die Rechenschaftspflicht #

Die Rechenschaftspflicht aus Art. 5 Abs. 2 verlangt, dass Sie die Einhaltung der Grundsätze nachweisen können. Den Verstoß muss die Aufsichtsbehörde belegen - aber Ihre Sorgfalt müssen Sie belegen. Wer hier nichts vorlegt, hat im Verfahren keine Verteidigungslinie. Deshalb ist die Dokumentation Ihr wichtigstes Einzelinstrument: Sie zeigt, welche Risiken Sie bewertet und welche Maßnahmen Sie tatsächlich getroffen haben.

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. Selbst wenn bei der Inbetriebnahme alle Bibliotheken gepflegt und ohne bekannte Schwachstellen waren: Einige Zeit später kann mehreres davon geschehen sein, ohne dass es jemand bemerkt:

Keine dieser Veränderungen löst bei Ihnen einen Alarm aus: Es gibt kein CVE, also meldet auch kein Scanner etwas. Für die DSGVO sind sie trotzdem unmittelbar relevant, weil sie die nach Art. 32 Abs. 1 lit. b geforderte dauerhafte Belastbarkeit untergraben. Und sie entscheiden mit über die rasche Wiederherstellbarkeit nach lit. c: Sicherungen allein bringen Sie zurück in den Betrieb - sicher weiterarbeiten können Sie erst, wenn jemand die Lücke schließt.

Eine Open-Source-Lizenz allein gibt Ihnen keine Zusage für Pflege oder Verfügbarkeit. 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 zählt, was Sie vorlegen können. Belegen Sie den Stand der Technik, die laufende Pflege und die getroffenen Maßnahmen: Nach Art. 83 Abs. 2 lit. d gehen sie ausdrücklich in die Bemessung ein - neben Schwere, Dauer und Mitwirkung. Je konkreter Ihre Nachweise, desto weniger Raum bleibt für die Annahme, Sie hätten das Risiko schlicht laufen lassen.

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.

Im laufenden Verfahren ist die dokumentierte Sorgfalt oft der letzte Hebel, der Ihnen bleibt.

Erstgespräch vereinbaren

DSGVO-Factsheet herunterladen (in Erstellung)

Weiterlesen #