Autor: Marcel Peter

  • Cookie-Banner-Nudging vor Gericht: Wenn „Ablehnen“ absichtlich schwerer zu finden ist

    Cookie-Banner-Nudging vor Gericht: Wenn „Ablehnen“ absichtlich schwerer zu finden ist

    Fast jede Website hat eines: ein Cookie-Banner, das beim ersten Besuch erscheint, meist mit einem großen, farbig hervorgehobenen Button „Alle akzeptieren“ und irgendwo daneben, kleiner, grauer, manchmal erst nach einem zweiten Klick erreichbar, die Möglichkeit abzulehnen. Diese Gestaltung ist kein Zufall, sie folgt einem bekannten Muster aus der Verhaltensökonomie: Nudging, das gezielte Schubsen einer Entscheidung in eine bestimmte Richtung durch Design statt durch Zwang. Das Verwaltungsgericht Hannover hat sich genau diese Praxis vorgenommen und ihr eine klare rechtliche Grenze gesetzt. Als erstinstanzliches Urteil ist die Entscheidung kein höchstrichterliches letztes Wort und Rechtsmittel sind grundsätzlich möglich, sie setzt aber ein deutliches Signal für die Praxis.

    Was das Gericht entschieden hat

    Das VG Hannover urteilte am 19. März 2025 (Az. 10 A 5385/22), dass ein manipulativ gestaltetes Cookie-Banner keine wirksame, freiwillige Einwilligung begründet, wenn „Alle akzeptieren“ visuell hervorgehoben ist, während die Ablehnoption versteckt oder erschwert zugänglich gestaltet wurde. Maßgeblich ist nach dieser Entscheidung, dass eine gleichwertige, unmittelbar sichtbare Ablehnoption vorhanden sein muss, also auf derselben Ebene, in vergleichbarer Größe und ohne zusätzlichen Klickaufwand gegenüber der Zustimmungsoption. Rechtlich gestützt wird das auf § 25 TTDSG (das Einwilligungserfordernis für den Zugriff auf Endgeräte-Informationen wie Cookies) in Verbindung mit Art. 4, 6 und 7 DSGVO, die definieren, was eine Einwilligung überhaupt ist und wann sie wirksam erteilt wurde.

    Klartext für Geschäftsführer: Ein Cookie-Banner zu haben reicht nicht. Wenn „Zustimmen“ groß, bunt und einen Klick entfernt ist, während „Ablehnen“ grau, klein oder über ein Untermenü versteckt ist, ist die dadurch eingeholte Einwilligung nach dieser Entscheidung unwirksam. Das betrifft nicht nur besonders aggressiv gestaltete Banner, sondern jede spürbare Asymmetrie zwischen den beiden Optionen.

    Was „gleichwertig“ konkret heißt

    Das Urteil liefert keine ausformulierte Pixel-für-Pixel-Checkliste, aber die Stoßrichtung ist eindeutig und deckt sich mit der Linie, die Aufsichtsbehörden und Rechtsprechung zu manipulativen Bannern seit Jahren verfolgen: Zustimmen und Ablehnen müssen auf derselben Interaktionsebene angeboten werden, ohne dass eine Option einen zusätzlichen Klick, ein Untermenü oder eine Scroll-Aktion erfordert, die die andere nicht braucht. Farbe, Kontrast und Button-Größe dürfen die Zustimmung nicht optisch bevorzugen, ein knalliges „Akzeptieren“ neben einem unauffälligen Textlink „Einstellungen“ oder „Ablehnen“ ist genau das Muster, das die Entscheidung adressiert. Eine Vorauswahl einzelner Cookie-Kategorien als bereits aktiviert („Alle Cookies“ oder auch nur „Marketing-Cookies“ vorab angehakt) unterläuft dieselbe Anforderung an eine informierte, freiwillige, aktive Erklärung und ist mit einer wirksamen Einwilligung im Sinne von Art. 4 Nr. 11, Art. 7 DSGVO nicht vereinbar.

    Klartext für Techniker: Drei Punkte konkret prüfen. Erstens, Button-Parität: „Ablehnen“ (oder „Alle ablehnen“) muss auf der ersten Ebene des Banners erscheinen, nicht erst nach Klick auf „Einstellungen“ oder „Details“. Zweitens, visuelle Gleichwertigkeit: keine auffällig andersfarbige oder größere Gestaltung für „Akzeptieren“ gegenüber „Ablehnen“, CSS-Klassen und Kontrastwerte der beiden Buttons direkt vergleichen. Drittens, keine vorangehakten Kästchen bei optionalen Kategorien, der Ausgangszustand jeder nicht technisch notwendigen Kategorie muss deaktiviert sein.

    Der Namenswechsel: TTDSG hieß damals so, heute TDDDG

    Die Vorschrift wurde bereits zum 14. Mai 2024 von TTDSG in TDDDG umbenannt (Telekommunikation-Digitale-Dienste-Datenschutz-Gesetz, vormals Telekommunikation-Telemedien- Datenschutz-Gesetz). Inhaltlich ist § 25 TDDDG dieselbe Norm; das Urteil vom 19. März 2025 verwendet mit § 25 TTDSG die zum Urteilszeitpunkt bereits veraltete, aber inhaltlich unveränderte frühere Bezeichnung. Korrekt zitiert man den Fall daher als „§ 25 TTDSG (heute § 25 TDDDG)“, statt die Bezeichnungen unkommentiert zu vermischen oder rückwirkend zu „korrigieren“.

    Warum das praktisch jede Website betrifft

    Anders als viele der Urteile in dieser Serie, die einzelne Tools oder Plattformen betreffen, geht es hier um die Grundausstattung fast jeder deutschen Unternehmenswebsite: das Cookie-Banner selbst. Viele Banner-Lösungen kommen als Standard-Konfiguration eines CMP-Anbieters (Consent-Management- Plattform) und werden beim Website-Launch einmal eingerichtet, oft mit werkseitig voreingestelltem Design, das genau das Muster zeigt, das dieses Urteil für unwirksam erklärt: prominentes „Akzeptieren“, unauffälliges „Ablehnen“. Ist die dadurch eingeholte Einwilligung unwirksam, fehlt für jedes darauf aufbauende Tracking, jeden Analytics-Aufruf, jedes Marketing-Pixel die Rechtsgrundlage, mit denselben Folgen wie in den anderen Artikeln dieser Serie beschrieben: Auskunfts-, Löschungs- und potenziell Schadensersatzansprüche der betroffenen Nutzer.

    Was für die Geschäftsführung zählt: Ein Cookie-Banner, das „Ablehnen“ gegenüber „Akzeptieren“ sichtbar benachteiligt, erzeugt nach dieser Entscheidung keine wirksame Einwilligung, egal wie professionell das Banner sonst aussieht. Das eigene Banner sollte konkret angeschaut werden, nicht nur, ob es vorhanden ist, sondern ob beide Optionen wirklich gleich leicht zu finden und zu klicken sind.

    Was für die Technik zählt: Banner-Konfiguration im CMP-Tool gegenprüfen: Button-Parität auf der ersten Ebene (kein Untermenü-Vorteil für „Ablehnen“), keine Farb-/Größen-Asymmetrie zwischen den beiden Haupt-Buttons, keine vorangehakten optionalen Kategorien. Viele CMP-Anbieter bieten dafür inzwischen ein eigenes „Ablehnen-Button“-Feature auf der Startebene, das oft nicht standardmäßig aktiviert ist und manuell zugeschaltet werden muss.

    Diese Entscheidung ist keine Ausnahmeentscheidung zu einem exotischen Einzelfall, sie trifft eine Gestaltungspraxis, die auf einem erheblichen Teil deutscher Websites bis heute Standard ist. Wer das eigene Banner zuletzt bei der Ersteinrichtung geprüft und seither nur „irgendwie funktioniert“ laufen lassen hat, sollte jetzt einen zweiten, genaueren Blick riskieren.

    Dieser Beitrag ist eine an die Allgemeinheit gerichtete Darstellung von Rechtsfragen und keine Rechtsdienstleistung (§ 2 Abs. 1 und Abs. 3 Nr. 5 RDG). Er prüft keinen Einzelfall und ersetzt keine anwaltliche Beratung. Maßgeblich ist allein der Gesetzestext in seiner geltenden Fassung; Stand: 19.07.2026.

  • SCHUFA & Bonitätsauskunfteien: fünf BGH-Urteile in 16 Monaten
    Symbolbild, KI-generiert

    SCHUFA & Bonitätsauskunfteien: fünf BGH-Urteile in 16 Monaten

    Kaum eine Datenverarbeitung betrifft so viele Menschen gleichzeitig wie die einer Wirtschaftsauskunftei: Jeder Kreditantrag, jeder Handyvertrag, jede Ratenzahlung hinterlässt eine Spur bei der SCHUFA. Zwischen Januar 2025 und Mai 2026 hat allein der Bundesgerichtshof fünf Urteile zu genau diesem Thema gefällt, in schneller Folge und mit bemerkenswerter Konsequenz. Zusammen zeichnen sie ein Bild davon, wie der BGH die Balance zwischen dem berechtigten Interesse der Auskunfteien und den Rechten der Betroffenen justiert.

    Der Ausgangspunkt: keine Strafzuschläge

    Den Auftakt macht chronologisch das älteste der fünf Urteile. Am 28. Januar 2025 entschied der BGH (VI ZR 183/22): Bei einer unberechtigten SCHUFA-Meldung ist für die Höhe des immateriellen Schadensersatzes allein die Ausgleichsfunktion maßgeblich. Verschuldensgrad und Schwere des Verstoßes wirken nicht straf- oder abschreckungsverstärkend. Wer also eine falsche Negativmeldung nachweislich erlitten hat, bekommt einen Ausgleich für den erlittenen Nachteil, keinen Denkzettel für die Auskunftei. Diese Linie war schon im ersten Teil dieser Serie als Randnotiz zu den neun Kernfällen rund um Art. 82 DSGVO aufgetaucht, hier steht sie am Anfang der eigentlichen SCHUFA-Kette.

    Keine Bagatellschwelle, aber Nachweispflicht bleibt

    Am 13. Mai 2025 zog der BGH (VI ZR 67/23) nach: Bei einer rechtswidrigen Negativmeldung gibt es keine Erheblichkeitsschwelle für immateriellen Schadensersatz nach Art. 82 Abs. 1 DSGVO. Ein kleiner Schaden bleibt ein Schaden. Gleichzeitig hält der BGH an der Nachweispflicht fest: Im konkreten Fall mussten die tatsächlichen negativen Folgen, hier Kreditkartenkündigungen, belegt werden. Wer betroffen ist, muss also nicht beweisen, dass der Schaden eine bestimmte Größenordnung erreicht, aber sehr wohl, dass überhaupt ein konkreter Nachteil entstanden ist.

    Klartext für Geschäftsführer: Eine fehlerhafte Meldung an die SCHUFA ist nicht deshalb ungefährlich, weil der Betroffene „nur“ eine gekündigte Kreditkarte und keinen ruinierten Kredit vorweisen kann. Der BGH verlangt keine Mindestschwelle. Er verlangt aber einen konkreten, belegbaren Nachteil, reines Unwohlsein reicht nicht.

    Betrugsprävention als berechtigtes Interesse

    Nicht jede Datenübermittlung an die SCHUFA ist automatisch problematisch. Am 14. Oktober 2025 entschied der BGH (VI ZR 431/24): Die Übermittlung von Mobilfunk-Positivdaten, also Vertragsabschluss, Vertragsbeendigung und Identifizierungsdaten, an die SCHUFA zur Betrugsprävention kann durch berechtigtes Interesse nach Art. 6 Abs. 1 Buchstabe f DSGVO gerechtfertigt sein. Eine Verbandsklage dagegen wurde abgewiesen. Der BGH erkennt damit an, dass Betrugsprävention ein legitimer Zweck ist, der eine Datenübermittlung tragen kann, auch ohne Einwilligung der Betroffenen.

    Löschfristen folgen eigener Logik

    Am 18. Dezember 2025 klärte der BGH (I ZR 97/25) eine Frage, die viele Betroffene intuitiv anders beantworten würden: Die maximale Speicherdauer von Zahlungsstörungsdaten bei Auskunfteien richtet sich nicht nach den Löschfristen anderer öffentlicher Register. Erledigte Forderungen müssen also nicht automatisch sofort gelöscht werden, nur weil beispielsweise ein Insolvenzregister seine Einträge früher entfernt. Maßgeblich ist stattdessen eine eigenständige Interessenabwägung, wobei die Verhaltensregeln nach Art. 40 DSGVO als Orientierung dienen können.

    Klartext für Techniker: Wer selbst Zahlungsdaten verarbeitet oder an Auskunfteien meldet, kann sich nicht pauschal an den Löschfristen anderer Register orientieren. Jede Speicherdauer-Entscheidung braucht eine eigene, dokumentierte Interessenabwägung, ein Verweis auf „das macht Register X doch auch so“ trägt rechtlich nicht.

    Das jüngste Urteil: scharfe Prüfung bei bestrittenen Forderungen

    Das bislang letzte der fünf Urteile stammt vom 12. Mai 2026 (BGH VI ZR 375/24): Eine rechtswidrige Negativmeldung an die SCHUFA kann den wirtschaftlichen Ruf beeinträchtigen und sowohl Schadensersatz als auch Widerruf begründen. Der BGH prüft dabei die Zulässigkeit der Datenübermittlung besonders genau, wenn die zugrunde liegende Forderung bestritten oder noch nicht gerichtlich tituliert ist. Wer also eine Forderung meldet, die der Schuldner ernsthaft bestreitet, ohne dass ein Titel vorliegt, geht ein erhebliches rechtliches Risiko ein.

    Die Urteile im Überblick

    DatumGerichtAz.Kernaussage
    28.01.2025BGHVI ZR 183/22Schadenshöhe folgt reiner Ausgleichsfunktion, kein Strafaufschlag
    13.05.2025BGHVI ZR 67/23Keine Bagatellschwelle, konkrete Folgen aber nachweispflichtig
    14.10.2025BGHVI ZR 431/24Betrugsprävention als berechtigtes Interesse bei Positivdaten
    18.12.2025BGHI ZR 97/25Speicherdauer folgt eigener Interessenabwägung, nicht anderen Registern
    12.05.2026BGHVI ZR 375/24Scharfe Prüfung bei bestrittener/nicht titulierter Forderung

    Was für die Geschäftsführung zählt: Wer Forderungen an eine Auskunftei meldet, ob selbst oder über einen Dienstleister, trägt das Risiko, wenn die Forderung bestritten oder nicht rechtskräftig festgestellt ist. Der wirtschaftliche Ruf eines Kunden ist ein anerkanntes Schutzgut, eine voreilige Negativmeldung kann teuer werden, auch ohne dass der Betroffene eine dramatische finanzielle Katastrophe nachweisen muss.

    Was für die Technik zählt: Datenübermittlungen an Auskunfteien, ob Negativ- oder Positivdaten, brauchen eine dokumentierte Rechtsgrundlage. Bei Betrugsprävention trägt oft ein berechtigtes Interesse, bei Zahlungsstörungsdaten eine eigenständige Interessenabwägung zur Speicherdauer. Pauschale Automatismen, weder bei der Meldung noch bei der Löschung, halten der BGH-Linie nicht stand.

    Diese Serie wird fortgesetzt: der nächste Teil widmet sich einem weiteren Cluster aus dem laufenden Content-Plan.

    Dieser Beitrag ist eine an die Allgemeinheit gerichtete Darstellung von Rechtsfragen und keine Rechtsdienstleistung (§ 2 Abs. 1 und Abs. 3 Nr. 5 RDG). Er prüft keinen Einzelfall und ersetzt keine anwaltliche Beratung. Maßgeblich ist allein der Gesetzestext in seiner geltenden Fassung; Stand: 19.07.2026.

  • Google AI Overviews vor Gericht: Was ein Münchner Urteil (noch) nicht entscheidet
    Symbolbild, KI-generiert

    Google AI Overviews vor Gericht: Was ein Münchner Urteil (noch) nicht entscheidet

    Wer heute etwas über ein Unternehmen sucht, bekommt bei Google oft zuerst keine Trefferliste mehr zu sehen, sondern eine von Künstlicher Intelligenz geschriebene Zusammenfassung direkt über den Ergebnissen. Diese sogenannten AI Overviews wirken wie eine neutrale Bündelung dessen, was das Netz hergibt. Das Landgericht München I hat Ende Mai entschieden, dass diese Zusammenfassungen etwas anderes sind: eine eigene Aussage von Google. Das Urteil ist frisch, es ist nicht rechtskräftig, und genau deshalb lohnt sich ein genauer Blick, statt einer vorschnellen Schlagzeile.

    Was das Gericht entschieden hat

    Am 28. Mai 2026 urteilte das LG München I (Az. 26 O 869/26), dass KI-generierte Suchergebnis-Übersichten, im konkreten Fall eine AI Overview über ein Unternehmen, keine bloße Wiedergabe fremder Suchtreffer sind, sondern eine eigenständige Aussage des Plattformbetreibers. Die rechtliche Einordnung: Google haftet für unwahre Inhalte in einer solchen KI-Zusammenfassung als unmittelbarer Störer, nicht nur mittelbar über eine Verlinkung auf fremde Quellen. Rechtlich ging es dabei um die Art. 4 bis 6 DSA, die regeln, wann Vermittlungsdienste für fremde Inhalte nicht haften, ein Privileg, das nach Auffassung des Gerichts für eine selbst formulierte KI-Zusammenfassung nicht greift.

    Klartext für Geschäftsführer: Bislang konnte sich Google bei fehlerhaften Inhalten oft darauf zurückziehen, nur eine automatisierte Trefferliste fremder Webseiten anzuzeigen, eine Art digitales Schaufenster ohne eigene Meinung. Das Münchner Gericht sagt: Eine KI-Zusammenfassung, die aktiv formuliert und zusammenfasst, ist keine Trefferliste mehr, sondern eine eigene Behauptung, für die Google selbst geradesteht, wenn sie falsch ist.

    Die entscheidende Einschränkung: nicht rechtskräftig

    Diese Klarstellung muss an dieser Stelle stehen, nicht als Fußnote am Ende: Das Urteil des LG München I ist eine erstinstanzliche Entscheidung. Es ist nicht rechtskräftig, eine Berufung ist möglich, und ob und wie ein Berufungsgericht (voraussichtlich das OLG München) die Frage der unmittelbaren Störerhaftung für KI-Zusammenfassungen bewertet, ist offen. Wer dieses Urteil zitiert, sollte es als das behandeln, was es ist: eine erste richterliche Positionierung zu einer neuen Technologie, kein feststehendes letztes Wort der Rechtsprechung. Gerade bei einem so neuen Themenfeld wie generativer KI in Suchmaschinen ist es plausibel, dass sich die rechtliche Bewertung in den kommenden Instanzen noch verschiebt, das Urteil ist eine Momentaufnahme, kein Schlusspunkt.

    Klartext für Techniker: Solange keine höherinstanzliche Bestätigung vorliegt, taugt dieses Urteil nicht als verlässliche Blaupause für eigene Rechtsdurchsetzung gegen Google. Es zeigt aber, in welche Richtung ein Gericht argumentiert hat, und das ist bereits ein Anhaltspunkt für die eigene Risikoeinschätzung.

    Warum das für KMU-Website-Betreiber trotzdem relevant ist

    Auch als nicht rechtskräftige Entscheidung verändert dieses Urteil die Ausgangslage für jedes Unternehmen, über das eine AI Overview etwas Unwahres zusammenfasst, sei es eine falsche Behauptung zur Geschäftstätigkeit, ein verzerrtes Bild aus veralteten oder falsch gewichteten Quellen, oder eine Zusammenfassung, die negative Einzelmeinungen als allgemeine Tatsache darstellt. Die Argumentationslinie des Gerichts, KI-Zusammenfassung gleich eigene Aussage, eröffnet potenziell einen direkteren Weg, gegen den Plattformbetreiber selbst vorzugehen, statt nur gegen die ursprüngliche Quelle der falschen Information.

    Gleichzeitig bleibt die praktische Hürde bestehen: Bevor irgendein rechtlicher Schritt Sinn ergibt, muss eine falsche AI-Overview-Zusammenfassung überhaupt entdeckt werden. AI Overviews werden nicht für jede Suchanfrage angezeigt, sie variieren je nach Nutzer, Standort und Zeitpunkt, und sie werden von Google laufend verändert. Ein Unternehmen, das eine falsche Zusammenfassung über sich findet, kann sie am nächsten Tag schon nicht mehr reproduzieren.

    Was jetzt sinnvoll ist, und was verfrüht wäre

    Es wäre verfrüht, aus einem einzelnen, nicht rechtskräftigen Urteil einen sicheren Anspruch gegen Google abzuleiten oder pauschale Beratung in diese Richtung zu geben. Sinnvoll ist dagegen, das eigene Unternehmen regelmäßig über gängige Suchbegriffe zu prüfen und Auffälligkeiten in einer AI Overview mit Datum, Screenshot und exakter Suchanfrage zu dokumentieren, falls sich die Rechtslage in den nächsten Monaten weiter festigt. Diese Dokumentation ist im Zweifel die Grundlage für alles Weitere, unabhängig davon, wie das Verfahren letztlich ausgeht.

    Was für die Geschäftsführung zählt: Ein einzelnes, nicht rechtskräftiges Urteil begründet noch keinen sicheren Rechtsanspruch, aber es zeigt eine Richtung, in die sich die Haftung für KI-Suchzusammenfassungen entwickeln könnte. Wachsamkeit gegenüber dem eigenen digitalen Erscheinungsbild in AI Overviews ist schon jetzt sinnvoll, unabhängig vom Ausgang der Berufung.

    Was für die Technik zählt: Sollte eine falsche AI-Overview-Zusammenfassung zum eigenen Unternehmen auftauchen, zählt eine saubere, zeitnahe Dokumentation (Screenshot, Suchanfrage, Datum, Standort/Gerät) mehr als eine sofortige rechtliche Reaktion, gerade weil sich die Anzeige jederzeit ändern oder verschwinden kann.

    Dieser Beitrag ist eine an die Allgemeinheit gerichtete Darstellung von Rechtsfragen und keine Rechtsdienstleistung (§ 2 Abs. 1 und Abs. 3 Nr. 5 RDG). Er prüft keinen Einzelfall und ersetzt keine anwaltliche Beratung. Maßgeblich ist allein der Gesetzestext in seiner geltenden Fassung; Stand: 19.07.2026. Das dargestellte Urteil ist nicht rechtskräftig, eine Berufung ist möglich; die endgültige rechtliche Bewertung steht noch aus.

  • Wann ein Datenschutzverstoß wirklich Geld kostet: Neun Urteile zu Art. 82 DSGVO
    Symbolbild, KI-generiert

    Wann ein Datenschutzverstoß wirklich Geld kostet: Neun Urteile zu Art. 82 DSGVO

    Ein Server wird gehackt, eine E-Mail-Adresse landet ungefragt im Newsletter-Verteiler, ein Auftragsverarbeiter löscht Daten nicht rechtzeitig, wandert die Sache dann vor Gericht, entscheidet sich vieles an einer einzigen Frage: Reicht der bloße Verstoß, oder braucht es einen konkret nachweisbaren Schaden? Neun Entscheidungen aus den letzten drei Jahren, vom EuGH bis zum BAG, zeichnen dazu eine Linie, die konsequenter ist, als viele Websitebetreiber annehmen.

    Der Ausgangspunkt: Österreichische Post

    Am 4. Mai 2023 stellte der EuGH in der Sache Österreichische Post klar (C-300/21): Ein bloßer Verstoß gegen die DSGVO genügt für sich genommen nicht für einen Schadensersatzanspruch nach Art. 82 Abs. 1 DSGVO. Es braucht einen Schaden. Gleichzeitig verneinte das Gericht aber eine Erheblichkeits- oder Bagatellschwelle, ein kleiner Schaden bleibt ein Schaden. Diese doppelte Aussage, kein Automatismus, aber auch keine Untergrenze, ist der Ankerpunkt für alles, was danach kommt.

    Die Erweiterung: Kontrollverlust reicht

    Am 18. November 2024 ging der BGH in der Facebook-Scraping-Entscheidung (VI ZR 10/24) einen entscheidenden Schritt weiter: Ein nachgewiesener bloßer Kontrollverlust über personenbezogene Daten kann bereits immateriellen Schaden begründen, konkrete Missbrauchsfolgen sind dafür nicht zwingend erforderlich. Diese Grundsatzentscheidung öffnete die Tür für eine ganze Reihe folgender Urteile.

    Am 4. September 2025 bestätigte der EuGH in der Sache Quirin Privatbank (C-655/23) diese Richtung von der europäischen Seite aus: Negative Gefühle wie Sorge oder Ärger können bei nachgewiesener Kausalität immateriellen Schaden begründen, der Verschuldensgrad des Verantwortlichen ist für die Schadenshöhe irrelevant. Gleichzeitig stellte der EuGH klar, dass die DSGVO selbst keinen eigenständigen unionsrechtlichen Unterlassungsanspruch vorsieht, Mitgliedstaaten aber nicht daran gehindert sind, einen solchen national vorzusehen.

    Zwei Fälle aus der betrieblichen Praxis zeigen, wie konkret das wird. Das OLG Düsseldorf sprach am 10. Juli 2025 (16 U 83/24, Deezer) 200 Euro Schadensersatz für einen kurzzeitigen Kontrollverlust nach einem Sicherheitsvorfall beim Auftragsverarbeiter zu, Verstöße des Auftragsverarbeiters gegen Löschungs- und Datenminimierungspflichten sind dem Verantwortlichen zurechenbar. Das BAG sprach am 8. Mai 2025 (8 AZR 209/21, Workday) ebenfalls 200 Euro zu, weil ein Arbeitgeber Echtdaten, darunter Gehaltsdaten, für einen Softwaretest über die Betriebsvereinbarung hinaus weitergegeben hatte, auch hier reichte ein kurzzeitiger Kontrollverlust.

    Klartext für Geschäftsführer: Ein Datenleck oder eine unbefugte Weitergabe von Kundendaten muss keine nachgewiesenen Betrugsfälle oder finanziellen Folgen für Betroffene nach sich ziehen, um teuer zu werden. Der bloße Umstand, dass Daten außer Kontrolle geraten sind, kann bereits genügen. Bei der Bemessung der Schadenshöhe zählt reine Ausgleichsfunktion, nicht Verschuldensgrad. Ergänzend, außerhalb der neun Kernfälle: Das hat der BGH schon am 28. Januar 2025 in einer SCHUFA-Sache (VI ZR 183/22) so entschieden.

    Die Gegenprobe: Ohne Nachweis kein Schaden

    Wer daraus liest, jeder Verstoß führe automatisch zu Geld, übersieht die Kehrseite. Das BAG wies am 5. Juni 2025 (8 AZR 117/24) eine Klage ab, weil DSGVO-Verstöße ohne konkret dargelegten materiellen oder immateriellen Schaden keinen Ersatzanspruch begründen, und mehrere gleichzeitig auftretende Verstöße in derselben Verarbeitung sind kein eigenständiger schadenserhöhender Faktor. Am 20. Februar 2025 entschied dasselbe Gericht (8 AZR 61/24), dass eine verspätete Auskunftserteilung allein noch keinen ersatzfähigen Schaden begründet, Kausalität muss konkret dargelegt werden, bloßes Verstimmt- oder Genervtsein genügt nicht. Und am 28. Januar 2025 bestätigte der BGH (VI ZR 109/23) zwar erneut die fehlende Erheblichkeitsschwelle, verlangte aber, dass konkrete negative Folgen und ein tatsächlicher Schaden dargelegt werden.

    Diese Fälle sind kein Widerspruch zur Kontrollverlust-Linie, sie ziehen nur die Grenze an einer anderen Stelle: Der Kontrollverlust selbst muss feststehen, eine bloße Behauptung oder ein rein hypothetisches Risiko reicht nicht. Wo genau die Beweisführung im Einzelfall ausreicht und wo nicht, das bleibt, ehrlich gesagt, eine Frage, die sich nicht mit einer einzigen Formel beantworten lässt, dafür sind die Sachverhalte zu unterschiedlich.

    Klartext für Techniker: Interne Sicherheitsvorfälle sauber dokumentieren, auch scheinbar kleine, kurzzeitige. Genau diese Dokumentation entscheidet später, ob eine Klage Erfolg hat oder nicht, in beide Richtungen.

    Die Fälle im Überblick

    DatumGerichtAz.Kernaussage
    04.05.2023EuGHC-300/21 (Österreichische Post)Kein Automatismus, aber keine Bagatellschwelle
    18.11.2024BGHVI ZR 10/24 (Facebook-Scraping)Bloßer Kontrollverlust kann Schaden sein
    28.01.2025BGHVI ZR 109/23Konkrete negative Folgen weiterhin nötig
    20.02.2025BAG8 AZR 61/24Verspätete Auskunft allein reicht nicht
    08.05.2025BAG8 AZR 209/21 (Workday)Echtdaten-Softwaretest, 200 Euro
    05.06.2025BAG8 AZR 117/24Kein Schaden ohne konkreten Nachweis
    10.07.2025OLG Düsseldorf16 U 83/24 (Deezer)Kontrollverlust bei Auftragsverarbeiter, 200 Euro
    04.09.2025EuGHC-655/23 (Quirin Privatbank)Negative Gefühle können Schaden sein, kein EU-Unterlassungsanspruch
    11.11.2025BGHVI ZR 396/24Löschpflicht nach Auftragsverarbeitung, Darknet-Fund als Schaden

    Was für die Geschäftsführung zählt: Ein Sicherheitsvorfall, auch ein vermeintlich kleiner, ist kein reines IT-Thema mehr, sondern ein konkretes finanzielles Risiko pro betroffener Person, selbst ohne nachgewiesenen Missbrauch. Gleichzeitig ist nicht jeder theoretische Verstoß automatisch teuer, entscheidend ist immer der Einzelfallbeweis.

    Was für die Technik zählt: Vorfälle beim eigenen Hoster oder Auftragsverarbeiter sind dem eigenen Unternehmen zurechenbar, das zeigen sowohl der Deezer- als auch der BGH-Fall zur Löschpflicht nach Vertragsende. Ein sauberes Löschkonzept mit dokumentierter Rückgabe- oder Löschbestätigung nach Beendigung einer Auftragsverarbeitung ist kein Papiertiger, sondern der Unterschied zwischen Haftung und Nicht-Haftung.

    Diese Serie wird fortgesetzt: als nächstes ein Blick auf die SCHUFA-Rechtsprechung, wo sich Art. 82 DSGVO mit dem Auskunfteirecht überschneidet.

    Dieser Beitrag ist eine an die Allgemeinheit gerichtete Darstellung von Rechtsfragen und keine Rechtsdienstleistung (§ 2 Abs. 1 und Abs. 3 Nr. 5 RDG). Er prüft keinen Einzelfall und ersetzt keine anwaltliche Beratung. Maßgeblich ist allein der Gesetzestext in seiner geltenden Fassung; Stand: 17.07.2026.

  • OLG Hamm verurteilt Meta: Was das Urteil für Websites mit Meta-Pixel bedeutet
    Symbolbild, KI-generiert

    OLG Hamm verurteilt Meta: Was das Urteil für Websites mit Meta-Pixel bedeutet

    Aktualisiert am 30.09.2026: Zuordnung der Betreiber-Verantwortung präzisiert, Stand des Rechtsmittels ergänzt.

    Der Meta-Pixel, das Conversion-API-Tracking, die Facebook-Login-Buttons, all das läuft unter dem Sammelbegriff „Meta Business Tools“ und ist auf vielen deutschen Unternehmenswebsites im Einsatz, oft seit Jahren, oft ohne dass jemand den rechtlichen Status regelmäßig neu geprüft hat. Das Oberlandesgericht Hamm hat am 9. März 2026 entschieden (Az. 8 U 21/25), dass Meta mit den Business Tools Daten von Nutzern auf fremden Websites und Apps ohne Rechtsgrundlage erhebt und mit deren Konto verknüpft (Art. 5, 6, 15, 17, 82 DSGVO). Beklagt war Meta, nicht ein Websitebetreiber.

    Was das Gericht konkret entschieden hat

    Verurteilt wurde Meta. Das Gericht stellt fest, dass Meta gemeinsam mit den Websitebetreibern für das Erfassen und Weiterleiten der Daten verantwortlich ist (Rn. 72) und sich davon nicht durch Verträge mit ihnen freizeichnen kann. Dass der Betreiber für genau diesen Schritt mitverantwortlich ist, hat der EuGH schon 2019 entschieden (Fashion ID, C-40/17): für das Erheben und Übermitteln der Daten, nicht für Metas spätere Auswertung. Der Klägerin sprach das Gericht gegen Meta Auskunft, Löschung und 1.500 € immateriellen Schadensersatz zu. Ob andere Nutzer Ansprüche haben, hängt vom Einzelfall ab.

    Klartext für Geschäftsführer: Wer die Tools einbindet, ist nach der EuGH-Rechtsprechung für das Erheben und Übermitteln der Besucherdaten mitverantwortlich und muss die dafür nötige Einwilligung selbst einholen (EuGH C-40/17, Tenor Nr. 2 und 4). Das OLG Hamm betont umgekehrt, dass auch Meta sich nicht hinter den Betreibern verstecken kann. Fehlt dem Betreiber diese Einwilligung, drohen ihm nicht nur Bußgelder, sondern auch Schadensersatzforderungen einzelner Nutzer.

    Warum „Einwilligung eingeholt“ allein nicht reicht

    Viele Websitebetreiber gehen davon aus, mit einem Cookie-Banner sei die Sache erledigt. Das Urteil befasst sich nicht mit einzelnen Cookie-Bannern. Es lässt aber Metas Einwand nicht gelten, bei korrekt eingerichtetem Banner fließe nichts: Als Mitverantwortliche müsse Meta selbst sicherstellen, dass die Betreiber die Tools richtig einbauen (Rn. 99 bis 101). Für Betreiber bleibt deshalb entscheidend, ob ihre eigene Einwilligung nach Art. 7 DSGVO und § 25 TDDDG trägt. Lädt ein Banner die Tools schon vor dem Klick, fehlt für diese Übermittlung die vorherige Einwilligung. Macht es das Ablehnen deutlich schwerer als das Zustimmen, ist die Freiwilligkeit angreifbar. Verwandt ist hier eine Entscheidung des VG Hannover vom 19. März 2025 (Az. 10 A 5385/22), die ein Cookie-Banner ohne Ablehnoption auf der ersten Ebene (nur ‚Alle akzeptieren‘, ‚Akzeptieren & schließen‘, ‚Einstellungen‘) als unwirksame Einwilligung eingestuft hat, weil es Nutzer gezielt zur Zustimmung lenkt.

    Klartext für Techniker: Prüfen, ob das Meta-Pixel-Skript technisch erst nach dem Consent-Klick lädt (Tag-Manager-Trigger-Bedingung), nicht schon beim Seitenaufruf mit nachgelagerter Deaktivierung. Und das Banner-Design gegenprüfen: Ist „Ablehnen“ genauso leicht zu finden und zu klicken wie „Akzeptieren“?

    Was das für den Alltag bedeutet

    Ein OLG-Urteil bindet zunächst nur die Parteien des konkreten Verfahrens, es entfaltet aber Signalwirkung für vergleichbare Fälle und zeigt, wie Gerichte diese verbreitete Konstellation aktuell bewerten. Für jeden, der Meta Business Tools einsetzt, heißt das: Die Frage „Ist unsere Einwilligungslösung wirklich wasserdicht?“ verdient eine erneute, ehrliche Antwort, nicht die Wiederholung dessen, was beim ursprünglichen Website-Launch einmal eingerichtet wurde.

    Was für die Geschäftsführung zählt: Nutzer, deren Daten ohne wirksame Einwilligung über Meta Business Tools erfasst wurden, können Auskunft verlangen, bei rechtswidriger Verarbeitung auch Löschung, und Schadensersatz, wenn sie einen Schaden darlegen. Ansprüche können sich gegen Meta richten und, gestützt auf die EuGH-Rechtsprechung zur gemeinsamen Verantwortung, für das Erheben und Übermitteln auch gegen den Betreiber.

    Was für die Technik zählt: Consent-Management-Plattform (CMP) und Tag-Manager-Konfiguration daraufhin prüfen, ob Meta-Skripte tatsächlich erst nach aktiver, informierter Einwilligung laden, ob die Ablehnoption gleichwertig sichtbar ist, und ob die Datenschutzerklärung die Meta-Business-Tools-Nutzung samt Drittlandaspekt korrekt beschreibt.

    Das OLG hat die Revision nicht zugelassen. Gegen das Urteil ist Nichtzulassungsbeschwerde beim Bundesgerichtshof eingelegt worden (Az. I ZR 154/26), es ist daher nicht rechtskräftig. Klar ist schon jetzt: Die bloße Tatsache, „irgendein Consent-Banner“ zu haben, schützt nicht automatisch vor genau dieser Haftungsfrage.

    Dieser Beitrag ist eine an die Allgemeinheit gerichtete Darstellung von Rechtsfragen und keine Rechtsdienstleistung (§ 2 Abs. 1 und Abs. 3 Nr. 5 RDG). Er prüft keinen Einzelfall und ersetzt keine anwaltliche Beratung. Maßgeblich ist allein der Gesetzestext in seiner geltenden Fassung; Stand: 30.09.2026.

  • KI-Musik, menschlicher Text: Was das SunoAI-Urteil für Unternehmen bedeutet
    Symbolbild, KI-generiert

    KI-Musik, menschlicher Text: Was das SunoAI-Urteil für Unternehmen bedeutet

    Ein Song, dessen Melodie eine künstliche Intelligenz komponiert hat, dessen Text aber ein Mensch geschrieben hat, wem gehört das eigentlich? Das Landgericht Frankfurt am Main hat am 17. Dezember 2025 genau diese Frage entschieden (Az. 2-06 O 401/25) und dabei etwas gemacht, das viele Unternehmen mit ihrer eigenen KI-Content-Praxis noch nicht auf dem Schirm haben: Es hat Text und Musik getrennt beurteilt.

    Der Fall

    Ein Musikstück war mit dem KI-Tool SunoAI vertont worden. Der Liedtext stammte jedoch nachweislich von einem Menschen. Das Gericht stellte fest: Dieser Text bleibt als eigenständiges Sprachwerk urheberrechtlich geschützt, unabhängig davon, mit welchem Mittel die Musik dazu erzeugt wurde (§ 2 Abs. 1 Nr. 1, §§ 16, 17, 97 UrhG). Die Verbreitung des fertigen Songs konnte deshalb untersagt werden, weil der Text ohne Erlaubnis genutzt worden war.

    Klartext für Geschäftsführer: Wer einen menschlich verfassten Text ohne Zustimmung des Autors mit einer KI vertonen lässt und das Ergebnis verbreitet, verletzt unter Umständen ein Urheberrecht, das an der KI-Beteiligung bei der Musik vorbeigeht. Der Text bleibt geschützt, ganz gleich, ob die Melodie von einem Menschen oder einer KI stammt.

    Warum das über den Einzelfall hinausgeht

    Das Urteil trennt sauber, was in der öffentlichen Debatte über „KI und Urheberrecht“ oft vermengt wird: Die Frage, ob ein KI-generiertes Ergebnis insgesamt geschützt ist, und die Frage, ob einzelne, menschlich geschaffene Bestandteile eines Werks ihren Schutz behalten, auch wenn der Rest maschinell erzeugt wurde. Für die zweite Frage gibt das Gericht eine klare Antwort: Ja, der menschliche Anteil bleibt geschützt.

    Das deckt sich mit einer Linie, die sich in der deutschen Rechtsprechung gerade erst bildet. Das Amtsgericht München hatte bereits am 13. Februar 2026 in einem anderen Fall (Az. 142 C 9786/25, KI-generierte Logos) entschieden, dass der urheberrechtliche Schutz von KI-generierten Werken vom Ausmaß des menschlich-schöpferischen Einflusses im Promptingprozess abhängt, also von der Schöpfungshöhe, die dieser Beitrag erreicht. Rein allgemein gehaltene Anweisungen ohne dominierenden kreativen Beitrag reichen dafür nicht. Beide Entscheidungen laufen auf denselben Grundgedanken hinaus: Es zählt der nachweisbare menschliche Schöpfungsanteil, nicht das Werkzeug.

    Klartext für Techniker: Bei gemischten Produktionen (Mensch schreibt, KI vertont oder umgekehrt) sollte dokumentiert werden, welcher Teil von wem stammt. Genau diese Zuordnung entschied hier den Fall.

    Was das für die tägliche Content-Praxis heißt

    Immer mehr Unternehmen, auch kleinere, nutzen KI-Tools für Social-Media-Jingles, Werbespots oder Hintergrundmusik in Videos. Das SunoAI-Urteil zeigt zwei Dinge gleichzeitig, und beide sind unangenehm für alle, die auf schnelle, klare Antworten hoffen: Erstens, KI-Vertonung macht einen fremden Text nicht automatisch frei nutzbar, wenn der Text selbst menschlich verfasst und geschützt ist. Zweitens, wer eigene, KI-unterstützt erzeugte Inhalte verbreitet, sollte im Streitfall belegen können, welcher Teil auf welcher schöpferischen Leistung beruht. Ein Verfahren, das die genaue Grenze zwischen „genug menschlicher Beitrag“ und „zu wenig“ für jede erdenkliche Konstellation zieht, gibt es bisher nicht, das bleibt Einzelfallbewertung.

    Was für die Geschäftsführung zählt: Wird für Marketing-Content ein fremder Text mit KI vertont oder anderweitig weiterverarbeitet, braucht es weiterhin die Zustimmung des Text-Urhebers, die KI-Beteiligung an der Musik ändert daran nichts. Bei eigenen KI-Produktionen lohnt sich eine kurze interne Dokumentation, wer welchen kreativen Beitrag geleistet hat, falls die Schutzfähigkeit später infrage steht.

    Was für die Technik/Redaktion zählt: Prompt-Historie und Zwischenstände bei KI-unterstützter Content-Produktion aufbewahren, das ist im Streitfall der Beleg für den menschlichen Anteil. Bei extern beauftragten oder online gefundenen Texten vor KI-Vertonung die Lizenzlage klären, unabhängig davon, welches KI-Tool danach zum Einsatz kommt.

    Zwei Fragen bleiben nach diesem Urteil offen: Wie viel menschlicher Eingriff in einem rein textlichen KI-Prompt reicht künftig für Schutz, und wie geht die Rechtsprechung mit rein KI-generierten Instrumentalstücken ohne jeden menschlichen Textanteil um? Beide Fragen sind noch nicht höchstrichterlich geklärt.

    Dieser Beitrag ist eine an die Allgemeinheit gerichtete Darstellung von Rechtsfragen und keine Rechtsdienstleistung (§ 2 Abs. 1 und Abs. 3 Nr. 5 RDG). Er prüft keinen Einzelfall und ersetzt keine anwaltliche Beratung. Maßgeblich ist allein der Gesetzestext in seiner geltenden Fassung; Stand: 17.07.2026.

  • SonicWall stellt Email Security ein: Was Sie jetzt prüfen müssen und welche EU-Alternativen wirklich souverän sind
    Symbolbild, KI-generiert

    SonicWall stellt Email Security ein: Was Sie jetzt prüfen müssen und welche EU-Alternativen wirklich souverän sind

    Stand 16. Juli 2026: SonicWall hat die Einstellung seiner gesamten Email-Security-Produktlinie offiziell bestätigt. Wir haben die Behauptung, die uns erreicht hat, nicht einfach übernommen, sondern gegen die offizielle SonicWall-Kommunikation und Herstellerangaben der genannten Alternativen geprüft. Das Ergebnis unten im Detail, inklusive der Stellen, an denen die kursierende Version zu ungenau war.

    Was tatsächlich abgekündigt wurde

    SonicWall hat im Februar 2026 die vollständige Einstellung der Email-Security-Produktlinie angekündigt und dies im Mai 2026 in der eigenen Partner-Kommunikation noch einmal bestätigt. Betroffen sind:

    • Email Security Software
    • die physischen Email-Security-Appliances (ESA-5000er-, 7000er- und 9000er-Serie)
    • die virtuellen Email-Security-Appliances
    • Hosted Email Security (Essential und Advanced Edition)
    • die zugehörigen TotalSecure-Email-Abo-Produkte

    Die Termine, geprüft gegen zwei unabhängige Quellen (SonicWall-eigener Partner-Blog und die offizielle EOL-Mitteilung):

    MeilensteinDatum
    Letzter Bestelltag30.04.2026
    Verkaufsstopp (End of Sale)01.05.2026
    Ende des Supports (End of Support)01.05.2027
    Abschaltung Hosted Email Security02.05.2027

    Die von Marcel weitergeleitete Vorlage nannte „Verkaufsende 30.04.2026“ und „End of Support 01.05.2027“: Das Verkaufsende deckt sich mit dem letzten Bestelltag, der formale Verkaufsstopp beginnt einen Tag später am 01.05.2026. Diese Präzisierung ist kein inhaltlicher Widerspruch, aber im Text der Vorlage nicht klar genug getrennt: Für Unternehmen mit laufenden Beschaffungsprozessen ist der Unterschied zwischen „letzter Bestelltag“ und „formaler Verkaufsstopp“ praktisch relevant.

    Begründung von SonicWall: Der klassische Secure-Email-Gateway-Ansatz (SEG) für On-Premises-Mailsysteme gilt aus Herstellersicht durch die Verlagerung der E-Mail-Infrastruktur zu Microsoft 365 und Google Workspace als überholt.

    GF-Klartext

    Wenn Ihr Unternehmen SonicWall-Email-Security-Hardware, eine virtuelle Appliance oder die Hosted-Variante im Einsatz hat: Ab 1. Mai 2027 gibt es keinen Hersteller-Support mehr, keine Firmware-Updates, keine neuen Signaturen gegen aktuelle Phishing-Wellen. Das ist keine sofortige Abschaltung, aber ein fest terminiertes Ablaufdatum für den Schutz Ihrer E-Mail-Kommunikation. Migrationsplanung jetzt beginnen, nicht erst 2027.

    Die Avanan-Empfehlung: bestätigt, mit einer Einordnung

    Die Vorlage behauptete, SonicWall verweise als Alternative auf Avanan. Das ist zutreffend. SonicWall benennt in der eigenen Abkündigungskommunikation ausdrücklich die bestehende Partnerschaft mit Avanan und empfiehlt den Umstieg auf cloudbasierte E-Mail-Sicherheit über diesen Weg.

    In der Vorlage fehlte allerdings eine wichtige Einordnung: Avanan ist seit 2021 Teil von Check Point Software Technologies und firmiert heute unter der Marke Check Point Harmony Email & Collaboration. Check Point ist ein israelisch-US-amerikanisches Unternehmen mit operativer Struktur in den USA (Check Point Software Technologies Ltd., Nasdaq-notiert). Wer von SonicWall zu Avanan/Check Point wechselt, wechselt also nicht in eine EU-souveräne Lösung, sondern von einem US-Hersteller (SonicWall, Kalifornien) zu einem weiteren nicht-EU-Anbieter. Für Unternehmen, denen reine Zweckerfüllung reicht, ist das unproblematisch. Für Unternehmen mit Souveränitäts-Anspruch (Kanzleien, Praxen, Behörden, KRITIS-nahe Betriebe) ist genau das der Anlass, jetzt breiter zu schauen.

    EU-Alternativen im Vergleich: nicht jede vermeintlich deutsche Lösung ist noch EU-souverän

    Wir haben sechs Kandidaten geprüft, die im Markt regelmäßig als „EU-“ oder „Made in Germany“-Alternative genannt werden. Das Ergebnis fällt gemischter aus, als die gängige Vermarktung suggeriert. Ein prominenter Anbieter aus dieser Liste ist seit Dezember 2025 nicht mehr EU-eigenständig.

    AnbieterSitzKernfunktionEU-SouveränitätBesonderheit
    HornetsecurityHannover, DeutschlandCloud-Gateway + M365-Security (Spamfilter, ATP, Backup, Awareness)Nein (seit 08.12.2025)Am 8. Dezember 2025 vollständig von Proofpoint (USA, im Besitz der US-Private-Equity-Gesellschaft Thoma Bravo) übernommen. Rechenzentren bleiben vorerst in der EU, die Konzernmutter unterliegt aber US-Recht (CLOUD Act/§ 702 FISA), genau die Drittland-Problematik, die eine EU-Alternative eigentlich vermeiden soll.
    RetarusMünchen, DeutschlandSecure Email Gateway, Verschlüsselung, Compliance-ArchivierungJaEigenbetriebene Rechenzentren in Deutschland (u. a. München), ISO-27001/22301/PCI-DSS-zertifiziert, kein bekannter US-Mutterkonzern, seit über 20 Jahren am Markt, breite Enterprise-Referenzbasis in DACH.
    NoSpamProxy (Net at Work)Paderborn, DeutschlandGateway-Spam-/Malware-Filter, S/MIME-/PGP-Verschlüsselung, Cloud- und On-Premises-VarianteJaInhabergeführter deutscher Mittelständler, über 15 Jahre am Markt, Siegel „IT Security Made in Germany“, vorgeschaltetes Gateway vor Microsoft 365/Exchange Online.
    Libraesva (LibraCyber)Lecco, ItalienKI-gestützte Gateway-Filterung, Phishing-Erkennung, seit April 2026 Zusammenschluss mit Cyber Guru zu LibraCyberJaSeit 2013 am Markt, EU-gehostete Infrastruktur, kein US-Mutterkonzern bekannt, Zusammenschluss mit Cyber Guru bleibt innerhalb Italiens/EU.
    eleven cyber security (eXpurgate, seit Februar 2026 umbenannt in Halon Classify)Berlin, DeutschlandCloud-natives Threat-Detection-Gateway (ML + menschliche Analyse)Ja, mit EinschränkungSeit September 2025 im Besitz von Halon, einem schwedischen E-Mail-Infrastrukturanbieter: Eigentümerwechsel bleibt innerhalb der EU, ist aber ebenfalls eine Übernahme und sollte vor Vertragsabschluss aktuell erfragt werden. Datenverarbeitung laut Anbieter weiterhin in zertifizierten deutschen Rechenzentren.
    SEPPmailSchweizGateway-Verschlüsselung (S/MIME, OpenPGP, GINA-Portal-Verschlüsselung)TeilweiseSchweiz ist kein EU-Mitgliedstaat, gilt aber datenschutzrechtlich über einen EU-Angemessenheitsbeschluss als sicheres Drittland. Kein US-Konzernbezug, aber eben auch kein EU-Rechtsraum im engeren Sinne. Fokus liegt zudem stärker auf Verschlüsselung als auf klassischer Spam-/Phishing-Gateway-Filterung.

    Nicht direkt vergleichbar, aber im Souveränitäts-Kontext oft genannt: Mailfence (Belgien) ist ein eigenständiger, verschlüsselter Mailbox-Dienst mit OpenPGP-Unterstützung und klar EU-souverän, aber kein vorgeschaltetes Security-Gateway für eine bestehende M365- oder Exchange-Umgebung. Für Unternehmen, die einen kompletten Mailbox-Wechsel statt eines vorgeschalteten Filters erwägen, ist er ein eigenes Thema, das den Rahmen dieses Artikels sprengt.

    GF-Klartext

    „EU-Anbieter“ ist keine feste Eigenschaft, sondern ein Zustand, der sich durch eine einzige Übernahme ändern kann: Hornetsecurity war bis Dezember 2025 das naheliegendste deutsche Gegenstück zu SonicWall/Avanan, gehört seither aber zu einem US-Konzern. Vor einer Vertragsunterschrift lohnt sich der Blick ins aktuelle Handelsregister beziehungsweise auf die Eigentümerstruktur des Anbieters, nicht nur auf den Marketingauftritt.

    Was bei der Migration technisch zu prüfen ist

    Unabhängig vom gewählten Anbieter gilt für alle SonicWall-Bestandskunden dieselbe Checkliste:

    1. Welche SonicWall-Email-Security-Variante ist im Einsatz? Hardware-Appliance, virtuelle Appliance, Software oder Hosted Service, das bestimmt die Migrationsschritte und den Zeitdruck (Hardware-Support endet formal ebenfalls am 01.05.2027, unabhängig vom Alter des Geräts).
    2. Läuft Ihre Domain aktuell als Gateway über eine SonicWall-Appliance (MX-Record zeigt auf SonicWall)? Dann ist bei der Migration ein MX-Record-Wechsel mit Übergangsfenster nötig, kein reiner Software-Tausch.
    3. Ist native Microsoft-365- oder Google-Workspace-Sicherheit bereits vorhanden? Ein Gateway-Wechsel muss auf die vorhandene Schutzschicht abgestimmt werden, doppelte Filterung kann zu Fehlklassifikationen führen.
    4. Gibt es archivierte, compliance-relevante E-Mail-Daten in der SonicWall-Umgebung? Diese müssen vor der Migration exportiert werden, spätestens mit dem Support-Ende sind Datenexporte nicht mehr garantiert.

    ExpertoMundi: Der Web-Audit zeigt den blinden Fleck

    In unserem kostenlosen Web-Audit für KMU, Kanzleien und Praxen prüfen wir auch, welche Dienstleister im Hintergrund Ihre E-Mail- und Website-Infrastruktur betreiben und welche davon durch Produktabkündigungen oder Konzern-Übernahmen zum stillen Sicherheitsrisiko werden können, bevor es zu spät ist.

    Jetzt kostenlosen Web-Audit anfordern

    Hinweis gemäß Rechtsdienstleistungsgesetz (RDG): Dieser Beitrag dient der allgemeinen Information und stellt keine Rechtsberatung im Einzelfall dar, insbesondere keine abschließende Bewertung einzelner Anbieter oder deren datenschutzrechtlicher Eignung für Ihren konkreten Fall. Die dargestellten Einordnungen beruhen auf öffentlich zugänglichen Herstellerangaben und Fachmedien (Stand: 16.07.2026). Eigentümerstrukturen von Unternehmen können sich ändern; vor Vertragsabschluss empfiehlt sich eine aktuelle Prüfung.

    Quellen (Abrufdatum 16.07.2026)

    • SonicWall, „Partner Power News, Mai 2026: Protection. Transition. Scale.“, offizieller SonicWall-Blog, sonicwall.com
    • SonicWall-Vertriebspartnerportal, „End of Life Announcement: SonicWall Email Security“, sonicwall-sales.com (autorisierte Repost-Quelle, datiert 04.02.2026)
    • Proofpoint, „Proofpoint Completes Acquisition of Hornetsecurity“, Pressemitteilung, 08.12.2025
    • Halon / eleven cyber security, Übernahme-Meldung eleven cyber security GmbH, September 2025
    • Retarus GmbH, Produktseite und Data-Center-Dokumentation „Secure Email Gateway“
    • Net at Work GmbH, Produktseiten NoSpamProxy Server/Cloud
    • Libraesva / LibraCyber, Unternehmensseite „About Libraesva“ und Pressemeldung Zusammenschluss mit Cyber Guru, April 2026
    • SEPPmail AG, Produktinformationen Secure E-Mail Gateway
    • Mailfence / ContactOffice Group SA, Unternehmensangaben
  • SonicWall SMA1000: Kritische Zero-Day-Lücken in Remote-Access-Gateways aktiv ausgenutzt
    Symbolbild, KI-generiert

    SonicWall SMA1000: Kritische Zero-Day-Lücken in Remote-Access-Gateways aktiv ausgenutzt

    Am 14. Juli 2026 hat SonicWall zwei Schwachstellen in seiner SMA1000-Produktreihe offengelegt, die zum Zeitpunkt der Veröffentlichung bereits aktiv von Angreifern ausgenutzt wurden. Beide Lücken stehen inzwischen im Known-Exploited-Vulnerabilities-Katalog (KEV) der US-Cybersicherheitsbehörde CISA. Wir haben die Angaben gegen die offizielle SonicWall-PSIRT-Advisory, die NVD-Einträge und mehrere unabhängige Fachquellen geprüft.

    Was ist betroffen

    Die SonicWall Secure Mobile Access (SMA) 1000 Series ist ein Remote-Access-Gateway: ein Gerät, über das Mitarbeitende von außen sicher auf interne Unternehmensanwendungen zugreifen, vergleichbar mit einem klassischen VPN-Konzentrator, nur mit zusätzlicher Anwendungssteuerung. Solche Geräte stehen naturgemäß am Rand des Netzwerks und sind über das Internet erreichbar, das ist ihr Zweck.

    Betroffen sind laut Advisory SNWLID-2026-0008 die Hardware-Modelle SMA6210 und SMA7210, die virtuelle Appliance SMA8200v sowie der Central Management Server (CMS), auf folgenden Versionen:

    • 12.4.3-03245, 12.4.3-03387, 12.4.3-03434
    • 12.5.0-02283, 12.5.0-02624, 12.5.0-02800

    Gefixt ist die Lücke in 12.4.3-03453 beziehungsweise 12.5.0-02835 und neueren Versionen.

    Die zwei Schwachstellen

    CVE-2026-15409 ist eine Server-Side-Request-Forgery-Lücke (SSRF, CWE-918) im „Work Place“-Interface der SMA1000-Appliance. Sie erreicht mit CVSS 10.0 den höchstmöglichen Schweregrad und ist von der NVD offiziell mit dem Vektor CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H bewertet: aus der Ferne, ohne Authentifizierung, ohne Nutzerinteraktion und mit vollem Verlust von Vertraulichkeit, Integrität und Verfügbarkeit ausnutzbar. Ein Angreifer kann das Gerät zwingen, Anfragen an von ihm gewählte Ziele zu senden.

    CVE-2026-15410 ist eine Command-/Code-Injection-Lücke in der Management-Konsole der SMA1000-Appliance, CVSS 7.2 (High), NVD stuft sie als post-authentifiziert ein: Ein bereits angemeldeter Administrator-Account kann darüber beliebige Betriebssystembefehle ausführen.

    Die eigentliche Gefahr liegt in der Kombination beider Lücken: Mehrere Fachquellen (Rapid7, BleepingComputer, The Hacker News) beschreiben, dass Angreifer die unauthentifizierte SSRF nutzen, um sich unautorisiert Zugang zu verschaffen, und anschließend die zweite Lücke anschließen, um mit Administratorrechten Code auszuführen. Aus einer Kette aus zwei Einzellücken wird so eine vollständige, unauthentifizierte Übernahme des Geräts von außen.

    GF-Klartext, Unternehmen ohne SMA1000-Einsatz: Diese konkrete Meldung betrifft Sie nicht direkt, wenn Sie kein SonicWall-Remote-Access-Gateway einsetzen. Sie zeigt aber ein wiederkehrendes Muster: Geräte, die absichtlich am Netzwerkrand stehen und von außen erreichbar sein müssen (Firewalls, VPN-Gateways, Remote-Access-Lösungen), sind ein bevorzugtes Angriffsziel, weil eine einzige Lücke dort direkt den Übergang ins interne Netz öffnet. Ein regelmäßiger Blick auf die eigene Edge-Infrastruktur lohnt sich unabhängig vom konkreten Hersteller.

    GF-Klartext, Unternehmen mit SMA1000-Einsatz: Wenn eines der genannten Modelle bei Ihnen im Einsatz ist, ist das keine Lücke unter vielen, sondern der wahrscheinlichste Weg für einen Angreifer, aus dem offenen Internet direkt in Ihr internes Netz zu gelangen, ohne ein Passwort zu benötigen. Beide US-Bundesbehörden-Fristen (siehe unten) und die bestätigte aktive Ausnutzung sprechen für sofortiges Handeln, nicht für den nächsten regulären Wartungstermin.

    Warum SSRF auf einem Edge-Gerät besonders kritisch ist

    Eine SSRF-Lücke erlaubt es einem Angreifer, ein Gerät dazu zu bringen, Anfragen an Ziele seiner Wahl zu senden, so, als käme die Anfrage vom Gerät selbst. Auf einem normalen internen Server ist das schon unangenehm. Auf einem Remote-Access-Gateway, das per Konstruktion Vertrauensstellungen zu internen Systemen besitzt (genau dafür ist es da: es soll Zugriff auf interne Anwendungen vermitteln), kann eine SSRF-Lücke genutzt werden, um interne Netzsegmente zu erreichen, die von außen eigentlich unerreichbar wären. In Kombination mit einer zweiten Lücke, die daraus Codeausführung macht, verwandelt sich das Gateway von einer Zugangskontrolle in ein offenes Tor.

    Bezug zu KRITIS und NIS2

    SMA1000-Geräte werden typischerweise von Unternehmen mit größerem Remote-Access-Bedarf eingesetzt, darunter auch Betreiber kritischer Infrastrukturen. Das bedeutet nicht automatisch, dass jeder SMA1000-Betreiber KRITIS- oder NIS2-pflichtig ist, das hängt von Sektor und Größe des Unternehmens ab. Wer aber ohnehin unter NIS2 fällt, sollte einen aktiv ausgenutzten CVSS-10.0-Fund an einem internetexponierten Zugangsgerät als klassischen Fall für die Meldepflicht bei erheblichen Sicherheitsvorfällen einordnen, sobald ein konkreter Kompromittierungsverdacht vorliegt (Betroffenheit ist hier ein Prüfhinweis, keine automatische Feststellung).

    CISA KEV-Aufnahme und Fristsetzung

    Beide CVEs wurden von der CISA in den Known-Exploited-Vulnerabilities-Katalog aufgenommen. Für US-Bundesbehörden gilt laut Binding Operational Directive (BOD) 26-04 eine Frist bis zum 17. Juli 2026, betroffene Systeme abzusichern oder den Einsatz einzustellen, sofern keine Mitigation möglich ist. Diese Frist bindet Marcels Kunden nicht direkt (keine US-Bundesbehörde), sie ist aber ein verlässlicher Indikator für den Ernst der Lage: Die CISA setzt solche Fristen nur bei bestätigter aktiver Ausnutzung.

    Handlungsempfehlung

    Priorität 1, sofort:

    1. Prüfen, ob eines der Modelle SMA6210, SMA7210, SMA8200v oder ein CMS im Einsatz ist und auf welcher Version.
    2. Bei betroffener Version umgehend auf 12.4.3-03453 beziehungsweise 12.5.0-02835 oder neuer aktualisieren (Hotfix über MySonicWall.com, laut SonicWall auch vorab über den SonicWall-Support erhältlich).
    3. Vor und unabhängig vom Update eine forensische Prüfung auf Kompromittierungsindikatoren (IOCs) durchführen (siehe unten). Aktive Ausnutzung bedeutet: Ein Patch schließt die Lücke für die Zukunft, beseitigt aber keinen bereits erfolgten Einbruch.
    4. Bei Fund eines IOC: Betroffene Appliance neu aufsetzen (Re-Image), nicht nur patchen. Alle Passwörter ändern, TOTP-Token zurücksetzen und neu ausrollen.
    5. Konfigurations-Backups nur verwenden, wenn sie nachweislich vor dem Dezember-Hotfix (12.4.3-03245 beziehungsweise 12.5.0-02283) erstellt wurden, ein Backup aus einer bereits verwundbaren Version kann den Kompromittierungszustand mit zurückspielen.

    Zu prüfende Indikatoren für Kompromittierung (IOC):

    • Einträge in extraweb_access.log mit Anfragen an /__api__/login oder /__api__/logout und HTTP-Statuscode 200.
    • Anfragen an /wsproxy mit auffälligen Host-Parametern und HTTP-Statuscode 101.
    • Einträge in ctrl-service.log mit dem Text „hotfix removal“ in Kombination mit Dateinamen, die Path-Traversal-Muster enthalten (etwa ../-Sequenzen).
    • Unautorisierte Routen in /var/lib/unit/conf.json.

    Fazit

    Zwei Lücken mit Höchst- beziehungsweise Hoch-Bewertung, bestätigt aktiv ausgenutzt, in Kombination miteinander verkettbar, auf einem Gerätetyp, der bewusst am Netzwerkrand steht: Das ist eine der eindeutigeren Prioritäts-1-Situationen in diesem Jahr. Wer SMA1000-Geräte betreibt, sollte Patch und IOC-Prüfung nicht getrennt behandeln, sondern beides parallel ansetzen. Ein regelmäßiger, unabhängiger Sicherheits-Check der eigenen Edge-Infrastruktur hilft, solche Abhängigkeiten frühzeitig zu erkennen, etwa mit unserem Auditor, der Consent- und Datenfluss-Risiken samt bekannter Schwachstellen in eingesetzter Software systematisch prüft.

    Quellen (Abrufdatum: 16.07.2026)

    • SonicWall PSIRT Advisory SNWLID-2026-0008: psirt.global.sonicwall.com/vuln-detail/SNWLID-2026-0008
    • SonicWall Product Notice: sonicwall.com/support/notices/product-notice-sma-1000-series-affected-by-multiple-vulnerabilities/kA1VN000001nv6D0AQ
    • NVD CVE-2026-15409: nvd.nist.gov/vuln/detail/CVE-2026-15409
    • CISA Known Exploited Vulnerabilities Catalog: cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2026-15409
    • BleepingComputer: bleepingcomputer.com/news/security/sonicwall-warns-of-sma1000-flaws-exploited-in-zero-day-attacks-patch-now/
    • Rapid7 MDR: rapid7.com/blog/post/etr-rapid7-mdr-team-discovers-new-sonicwall-sma1000-zero-days-being-actively-exploited-cve-2026-15409-cve-2026-15410/
    • The Hacker News: thehackernews.com/2026/07/two-sonicwall-sma-1000-zero-days.html
    • Help Net Security: helpnetsecurity.com/2026/07/14/sonicwall-sma-attacks-via-cve-2026-15409-cve-2026-15410/
    • SecurityWeek: securityweek.com/sonicwall-issues-urgent-sma-patch-warning-for-two-zero-day-exploits/
    • Security Affairs (CISA-KEV-Meldung): securityaffairs.com/195383/security/u-s-cisa-adds-sonicwall-and-microsoft-flaws-to-its-known-exploited-vulnerabilities-catalog.html
  • Warum ein Passwort allein nicht reicht
    Symbolbild, KI-generiert

    Warum ein Passwort allein nicht reicht

    Für Geschäftsführer: Was bedeutet das für mein Risiko und meine Kosten

    Der Admin-Login Ihrer Webseite, ob WordPress, ein anderes Content-Management-System oder ein Kundenportal, ist eines der attraktivsten Ziele für Angreifer. Wird er kompromittiert, verlieren Sie nicht nur die Kontrolle über Ihre Webseite, sondern riskieren auch, dass Kundendaten abfließen, Schadsoftware auf Ihrer Seite platziert wird oder Ihre Domain für Phishing-Kampagnen missbraucht wird, mit entsprechenden Folgen für Reputation und im Fall personenbezogener Daten auch für Ihre DSGVO-Haftung.

    Viele Unternehmen verlassen sich dabei ausschließlich auf ein „sicheres Passwort“. Das reicht heute nicht mehr aus, aus einem einfachen Grund: Angreifer müssen ein Passwort meist gar nicht erraten, sie automatisieren den Login-Versuch. Ein Skript probiert in kurzer Zeit tausende Kombinationen durch (Brute-Force), oder es nutzt Zugangsdaten, die bei einem ganz anderen, längst gehackten Onlinedienst gestohlen wurden, in der Hoffnung, dass Mitarbeitende dasselbe Passwort mehrfach verwenden (Credential-Stuffing). Beide Angriffe laufen vollautomatisch, rund um die Uhr, ohne dass ein Mensch Ihr Passwort „erraten“ müsste.

    Die gute Nachricht: Die wirksamsten Gegenmaßnahmen sind technisch überschaubar und meist ohne große Investition umsetzbar. Eine Begrenzung fehlgeschlagener Login-Versuche, eine zweite Bestätigungsstufe beim Anmelden (Multi-Faktor-Authentifizierung) und eine Zugriffsbeschränkung auf den Admin-Bereich schließen die Lücke, die ein Passwort allein offenlässt. Für Unternehmen, die unter das NIS2-Umsetzungsgesetz fallen, ist das genau die Multi-Faktor-Authentifizierung, die §30 Abs. 2 Nr. 10 BSIG ausdrücklich verlangt. Aber auch unabhängig von einer gesetzlichen Pflicht gehört ein gehärteter Login heute zum Mindeststandard einer professionell betriebenen Webseite.

    Kurz gesagt: Ein starkes Passwort ist die Grundvoraussetzung, aber allein ist es eine Tür ohne zweites Schloss. Die im Folgenden beschriebenen Maßnahmen sind der zweite Schlüssel.

    Für Techniker: Konkrete Härtungsmaßnahmen

    1. Warum das Passwort allein versagt

    Ein Login-Formular, das beliebig viele Versuche ohne Sperre zulässt, ist gegen automatisierte Angriffe praktisch offen. Zwei Angriffsklassen dominieren:

    • Brute-Force: Systematisches Durchprobieren von Zeichenkombinationen oder gängigen Passwortlisten gegen ein bekanntes Benutzerkonto (häufig „admin“).
    • Credential-Stuffing: Wiederverwendung von Zugangsdaten aus früheren, öffentlich gewordenen Datenlecks anderer Dienste. Dieser Angriff funktioniert unabhängig davon, wie stark Ihr Passwort ist, er nutzt aus, dass Menschen Passwörter über mehrere Dienste hinweg wiederverwenden.
    • Phishing: Angreifer erschleichen sich das Passwort direkt, etwa über eine gefälschte Login-Seite, die per E-Mail verlinkt wird. Auch hier hilft die Komplexität des Passworts nichts, weil es freiwillig eingegeben wird.

    Gegen alle drei Klassen bietet ein einzelner Faktor (nur das Passwort) keinen strukturellen Schutz, es braucht zusätzliche, unabhängige Kontrollmechanismen.

    2. Rate-Limiting / Login-Versuchs-Begrenzung

    Die einfachste wirksame Maßnahme: Nach einer definierten Anzahl fehlgeschlagener Login-Versuche wird die IP-Adresse oder das Benutzerkonto temporär gesperrt (z. B. 5 Versuche, dann 15 bis 60 Minuten Sperre, exponentiell ansteigend bei Wiederholung). Für WordPress existieren dafür etablierte Plugins wie „Limit Login Attempts Reloaded“; bei eigenentwickelten oder anderen CMS-Systemen lässt sich dasselbe Prinzip serverseitig (z. B. über fail2ban oder auf Ebene des Reverse Proxys) umsetzen. Wichtig: Die Sperre sollte sich nicht ausschließlich auf die IP-Adresse verlassen, da Angreifer über Botnetze mit wechselnden IPs arbeiten, eine Kombination aus IP- und Konto-basierter Begrenzung ist robuster.

    3. Multi-Faktor-Authentifizierung (MFA)

    MFA verlangt beim Login einen zweiten, unabhängigen Nachweis zusätzlich zum Passwort, etwa einen zeitbasierten Code aus einer Authenticator-App (TOTP) oder einen Hardware-Sicherheitsschlüssel. Selbst wenn ein Angreifer das korrekte Passwort besitzt (durch Phishing oder Credential-Stuffing), scheitert der Login ohne den zweiten Faktor. Für WordPress gibt es dafür geprüfte Plugins; viele CMS-Systeme und Verwaltungspanels bringen MFA-Unterstützung mittlerweile nativ mit. Aus regulatorischer Sicht ist das genau die Multi-Faktor-Authentifizierung, die §30 Abs. 2 Nr. 10 BSIG ausdrücklich verlangt.

    4. IP-Allowlist / Web Application Firewall für den Admin-Bereich

    Wo es organisatorisch möglich ist (feste Büro-IP, VPN-Zugang), lässt sich der Zugriff auf /wp-admin beziehungsweise das jeweilige Admin-Interface auf bekannte IP-Adressen beschränken, etwa über die Webserver-Konfiguration (Apache/Nginx) oder eine vorgeschaltete Web Application Firewall (WAF). Das reduziert die Angriffsfläche drastisch: Ein Angreifer, der nicht aus dem erlaubten IP-Bereich kommt, sieht den Login gar nicht erst. Bei wechselnden Standorten oder Homeoffice-Betrieb ist eine WAF-Lösung mit Bot- und Anomalie-Erkennung die praktikablere Alternative zu einer starren IP-Liste.

    5. Passwort-Qualität und Passkeys

    Auch wenn das Passwort allein nicht ausreicht, bleibt es ein notwendiger Baustein: ausreichend lang, pro Dienst einzigartig, idealerweise aus einem Passwort-Manager generiert. Zunehmend verbreitet sich außerdem der Passkey-Standard (FIDO2/WebAuthn), bei dem statt eines Passworts ein kryptografisches Schlüsselpaar verwendet wird, das grundsätzlich resistent gegen Phishing ist, weil es an die konkrete Domain gebunden ist und sich nicht auf einer gefälschten Seite eingeben lässt.

    Zusammengefasst: Rate-Limiting verhindert das automatisierte Durchprobieren, MFA macht ein gestohlenes Passwort allein wertlos, eine IP-Beschränkung oder WAF reduziert die sichtbare Angriffsfläche, und ein sauberes Passwort beziehungsweise ein Passkey bleibt die Basis. Keine dieser Maßnahmen ersetzt die anderen, ihre Kombination ergibt die eigentliche Härtung.

  • Was NIS2 & DORA technisch von Ihrer Website verlangen, und für wen sie gelten
    Symbolbild, KI-generiert

    Was NIS2 & DORA technisch von Ihrer Website verlangen, und für wen sie gelten

    Stand der Korrektur 06.11.2026: Wen DORA erfasst, die Größenschwelle nach § 28 BSIG und die KRITIS-Schwellenwerte sind richtiggestellt; ergänzt sind die Zusatzpflichten für Betreiber kritischer Anlagen, präzisiert ist die Haftung der Geschäftsleitung.

    Für Geschäftsführer: Was bedeutet das für mein Risiko und meine Kosten

    Seit dem 6. Dezember 2025 gilt in Deutschland das NIS2-Umsetzungsgesetz (BSIG-2025). Es verpflichtet tausende Unternehmen, ihre IT-Sicherheit auf ein nachweisbares Mindestniveau zu heben, darunter auch Anforderungen, die sich direkt an der eigenen Webseite und am eigenen Mailserver ablesen lassen. Parallel gilt seit Januar 2025 die europäische DORA-Verordnung für nahezu den gesamten Finanzsektor, mit ähnlichen technischen Kernpflichten.

    Die gute Nachricht zuerst: Ein Großteil dessen, was NIS2 §30 BSIG technisch fordert, lässt sich mit einem einzigen automatisierten Scan prüfen, TLS-Verschlüsselung, Zertifikate, Sicherheits-Header, Mail-Absicherung und bekannte Schwachstellen. Diese Prüfpunkte sind zugleich der technische Kern von DORA (Artikel 9 der Verordnung) und der KRITIS-Anforderungen des BSI. Wer hier sauber aufgestellt ist, bedient drei Rahmenwerke gleichzeitig, unabhängig davon, ob er formal darunterfällt.

    Die schlechte Nachricht: Ob Sie überhaupt unter NIS2, DORA oder KRITIS fallen, ist keine rein technische Frage. Es hängt von Ihrer Branche, Ihrer Unternehmensgröße (vereinfacht: mindestens 50 Mitarbeitende, oder mehr als 10 Millionen Euro Umsatz zusammen mit mehr als 10 Millionen Euro Bilanzsumme; Zahlen verbundener Unternehmen und anteilig die von Partnerunternehmen zählen grundsätzlich mit, die genaue Schwelle ist im Einzelfall zu prüfen) und, im Fall von KRITIS, von den Schwellenwerten ab, die derzeit die BSI-Kritisverordnung je Anlagenart festlegt. Sie leiten sich meist aus einem Regelwert von 500.000 versorgten Personen ab und sind deshalb je Anlage verschieden, bei einem Krankenhaus etwa 30.000 vollstationäre Fälle im Jahr, bei einem Rechenzentrum 3,5 Megawatt vertraglich vereinbarte Leistung. Diese Einordnung kann und will ein technischer Scan nicht abschließend leisten, das wäre Rechtsberatung. Was er leisten kann: Ihnen zeigen, wo Ihre Technik heute steht, und Ihnen einen begründeten Hinweis geben, ob eine nähere Prüfung Ihrer Betroffenheit sinnvoll ist.

    Warum das für Sie als Geschäftsführung relevant ist: Bei NIS2-pflichtigen Unternehmen muss die Geschäftsleitung die Risikomanagement-Maßnahmen umsetzen und ihre Umsetzung überwachen; verletzt sie diese Pflicht schuldhaft, haftet sie ihrem Unternehmen persönlich für den Schaden, nach den Regeln des Gesellschaftsrechts (§ 30 i. V. m. § 38 Abs. 1 und 2 BSIG). Verstöße gegen Melde- und Nachweispflichten können mit empfindlichen Bußgeldern geahndet werden. Und selbst wenn Sie formal nicht betroffen sind, gelten die gleichen technischen Mindeststandards vielerorts längst als „Stand der Technik“, ein Kriterium, das auch außerhalb von NIS2 in Haftungsfragen herangezogen wird (etwa bei der DSGVO oder im Wettbewerbsrecht).

    Kurz gesagt: Ein technischer Website- und Mail-Scan ist keine Formalität, sondern der schnellste Weg, den eigenen Status zu kennen, bevor eine Aufsichtsbehörde oder ein Vorfall ihn für Sie klärt.

    Für Techniker: Was konkret geprüft wird und wie Sie es selbst nachvollziehen

    NIS2 (Richtlinie (EU) 2022/2555, national umgesetzt im BSIG-2025) verlangt in §30 Absatz 2 zehn Kategorien von Risikomanagement-Maßnahmen. Nur ein Teil davon ist an einer Webseite technisch messbar, der Rest betrifft Prozesse (Schulungen, Backup-Konzepte, Krisenmanagement), die sich nicht scannen lassen. Konkret prüfbar sind vor allem:

    Transportverschlüsselung (§30 Abs. 2 Nr. 8, BSI TR-03116-4):

    • Nur TLS 1.2 und 1.3 aktiv, ältere Protokollversionen (SSLv3, TLS 1.0/1.1) deaktiviert (RFC 8996)
    • Ausschließlich Perfect-Forward-Secrecy-Cipher (ECDHE) mit AEAD-Verschlüsselung (AES-GCM)
    • Schlüssellängen ab 3072 Bit bei RSA/DH, moderne elliptische Kurven
    • Gültiges Zertifikat einer vertrauenswürdigen Zertifizierungsstelle, keine abgelaufenen oder fehlerhaften Ketten
    • TLS-Kompression deaktiviert (Schutz gegen CRIME-Angriffe), Client-Renegotiation aus, OCSP-Stapling aktiv

    Sicherheits-Header (OWASP-Empfehlung, IT-Grundschutz-Baustein APP.3.1, nicht Teil von TR-03116-4):

    • HSTS mit ausreichender max-age und includeSubDomains
    • Restriktive Content-Security-Policy
    • X-Content-Type-Options: nosniff, Referrer-Policy, Klickjacking-Schutz
    • Cookie-Attribute Secure, HttpOnly, SameSite
    • Erzwungene HTTPS-Weiterleitung ohne Mixed Content

    Mail-Sicherheit (§30 Abs. 2 Nr. 8, BSI TR-03108):

    • SPF-Record mit striktem Fail-Mechanismus
    • DKIM mit mindestens 2048 Bit Schlüssellänge
    • DMARC mit p=quarantine oder p=reject und Reporting-Adresse
    • DNSSEC-signierte Zone plus DANE/TLSA-Records für den Mailserver
    • MTA-STS im Enforce-Modus und TLS-RPT-Reporting

    Ergänzend gehört zur gesicherten Kommunikation nach §30 Abs. 2 Nr. 10 BSIG auch die Multi-Faktor-Authentifizierung (MFA) für Admin- und Login-Zugänge. Sie lässt sich nicht direkt am TLS- oder Mail-Scan ablesen, ist aber ein zentraler Baustein der geforderten Login-Härtung.

    Meldekanal für Schwachstellen (§30 Abs. 2 Nr. 2/5):

    • /.well-known/security.txt nach RFC 9116, mit gültigem Contact-Feld und Expires-Datum unter einem Jahr, ausgeliefert über HTTPS

    Lieferketten- und Patchstand-Indikatoren (§30 Abs. 2 Nr. 4/5):

    • Eingebundene Drittanbieter-Skripte, CDNs und Tag-Manager sichtbar machen
    • Erkennbare veraltete Server- oder CMS-Versionen und öffentlich bekannte Schwachstellen (CVEs)

    DORA (Verordnung (EU) 2022/2554, seit 17. Januar 2025 anwendbar) richtet sich vor allem an Finanzunternehmen im Sinne von Artikel 2 Abs. 2 (Banken, Versicherungen, Zahlungs- und E-Geld-Institute, Wertpapierfirmen, Krypto-Dienstleister und weitere). Daneben nennt Artikel 2 Abs. 1 Buchst. u auch IKT-Drittdienstleister, also Unternehmen, die IKT-Dienstleistungen bereitstellen. Sie erreicht DORA vor allem über die Verträge mit ihren Finanzkunden (Artikel 30) und unmittelbar unter Aufsicht erst, wenn sie als kritisch eingestuft werden (Artikel 31). Für Finanzunternehmen ist DORA lex specialis, sie geht der NIS2-Anwendung vor. Der weit überwiegende Teil von DORA ist organisatorisch (Governance, Asset-Inventar, Incident-Reporting, bedrohungsgeleitete Pentests). Der technisch scanbare Kern deckt sich jedoch weitgehend mit dem NIS2-Katalog: Transportverschlüsselung nach Artikel 9 DORA in Verbindung mit den technischen Regulierungsstandards (RTS, Delegierte Verordnung (EU) 2024/1774, Artikel 6 und 14).

    KRITIS (BSI-KritisV, Schwellenwerte je Anlagenart) ist die höchste Stufe: Jeder Betreiber einer kritischen Anlage gilt automatisch als „besonders wichtige Einrichtung“ (§ 28 Abs. 1 Nr. 1 BSIG). Die technische Baseline von oben gilt auch hier. Für die IT, die für die kritische Anlage maßgeblich ist, gilt aber ein strengerer Maßstab: Auch Maßnahmen über das Schutzniveau besonders wichtiger Einrichtungen hinaus gelten dort als verhältnismäßig, und Systeme zur Angriffserkennung sind Pflicht (§ 31 BSIG; Sonderregeln gelten unter anderem für Energie, Telekommunikation und den Finanzsektor).

    Wichtig für die korrekte Einordnung: HSTS und Content-Security-Policy werden häufig fälschlich der BSI-Richtlinie TR-03116-4 zugeschrieben. Tatsächlich behandelt TR-03116-4 ausschließlich den TLS-Handshake selbst (Protokollversion, Cipher, Schlüssel, Zertifikat). Sicherheits-Header sind OWASP-Best-Practice und Teil des IT-Grundschutz-Bausteins APP.3.1. Diese Unterscheidung ist keine Spitzfindigkeit, sie entscheidet, welchen Prüfpunkt Sie in einem Audit-Bericht welchem Rahmenwerk zuordnen dürfen.

    Was ein Scan nicht leisten kann: Ob Sie überhaupt NIS2-, DORA- oder KRITIS-pflichtig sind, folgt aus Sektor- und Größenkriterien, die sich nicht zuverlässig aus einer Webseite ablesen lassen. Ein seriöses Audit-Tool sollte diese Einordnung daher immer als Hinweis beziehungsweise Annahme kennzeichnen, nicht als abschließendes Verdikt, und bei fehlender Betroffenheit ausdrücklich sagen, dass die geprüften Punkte technisch trotzdem als Stand der Technik empfohlen bleiben.

    Dieser Beitrag ist eine an die Allgemeinheit gerichtete Darstellung von Rechtsfragen und keine Rechtsdienstleistung (§ 2 Abs. 1 und Abs. 3 Nr. 5 RDG). Er prüft keinen Einzelfall und ersetzt keine anwaltliche Beratung. Maßgeblich ist allein der Gesetzestext in seiner geltenden Fassung; Stand: 15.07.2026, korrigiert am 06.11.2026.

WhatsApp