Autor: Marcel Peter

  • Wenn Mitarbeitende zu Verantwortlichen werden: Der Berliner Datenschutzbericht zu Gesundheitsdaten
    Symbolbild, KI-generiert

    Wenn Mitarbeitende zu Verantwortlichen werden: Der Berliner Datenschutzbericht zu Gesundheitsdaten

    Die Berliner Beauftragte für Datenschutz und Informationsfreiheit (BlnBDI) hat ihren Jahresbericht 2025 veröffentlicht. Ein Abschnitt beschäftigt sich mit einem Muster, das in jedem Betrieb mit sensiblen Daten auftreten kann: Beschäftigte nutzen Zugriffsrechte, die sie für ihre Arbeit haben, für private Zwecke.

    Drei Fälle aus dem Gesundheitsbereich stehen im Bericht. Ein Mitarbeiter drehte private Filmaufnahmen in einer Klinik und gab sie weiter, der Bußgeldbescheid dazu ist inzwischen rechtskräftig. Ein Arzt rief ohne Anlass die Gesundheitsdaten einer ihm unterstellten Beschäftigten ab und prüfte außerdem unbefugt den Infektionsstatus eines Assistenzarztes, auch hier wurde ein Bußgeld verhängt. Ein Rezeptionist einer psychiatrischen Ambulanz nutzte die private E-Mail-Adresse einer Patientin, um sie außerhalb des Praxisbetriebs privat anzuschreiben, das Bußgeld dazu erging bereits im Vorjahr. Konkrete Beträge oder Aktenzeichen nennt der Bericht für diese drei Fälle nicht.

    Was rechtlich passiert: Sobald jemand Daten, auf die er beruflich zugreifen darf, für einen privaten Zweck verarbeitet, wird nach Auffassung der Behörde die betreffende Person selbst zur Verantwortlichen im Sinne der DSGVO, nicht mehr die Klinik oder Praxis. Und weil kein beruflicher Anlass mehr besteht, fehlt für diese private Verarbeitung in aller Regel jede Rechtsgrundlage. Bei Gesundheitsdaten kommt erschwerend hinzu: Sie zählen zu den besonderen Kategorien personenbezogener Daten nach Art. 9 DSGVO, für die ein noch engerer Rahmen gilt als für gewöhnliche Daten.

    Das Muster reicht weit über Kliniken hinaus: Das Muster ist branchenunabhängig. Wer als Personalverantwortlicher Zugriff auf Gehaltsdaten hat, wer als IT-Admin Postfächer einsehen kann, wer als Vertriebler die Kundendatenbank durchsuchen darf, sitzt im selben Risiko. Die Frage ist nicht, ob der Zugriff technisch möglich war, sondern ob er für die konkrete Aufgabe nötig war.

    Was die Behörde von Arbeitgebern erwartet: Der Bericht nennt zwei Punkte. Erstens technisch-organisatorische Maßnahmen, die unbefugte Verarbeitungen von vornherein erschweren, etwa Zugriffsbeschränkungen nach dem Prinzip der minimalen Berechtigung und Protokollierung sensibler Abfragen. Das ist die praktische Umsetzung von Art. 32 DSGVO, der Verantwortliche zu angemessenen Sicherheitsmaßnahmen verpflichtet. Zweitens regelmäßige Schulungen, damit allen Beschäftigten klar ist, wo die Grenze zwischen dienstlichem und privatem Datenzugriff verläuft.

    Für die Praxis heißt das: Ein Zugriffskonzept, das nur auf dem Papier existiert, schützt niemanden. Wer prüfen will, ob im eigenen Betrieb nachvollziehbar ist, wer wann auf welche sensiblen Daten zugegriffen hat, sollte genau dort ansetzen, bevor die Aufsichtsbehörde es tut.


    Quelle: BlnBDI, Jahresbericht 2025, Abschnitt B-II-3, abgerufen am 08.07.2026 unter datenschutz-berlin.de/jahresbericht-2025/#B-II-3.

    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: 11.07.2026.

  • 65.000 Euro Bußgeld für gekaufte Adressdaten: Was der Fall für jedes Unternehmen bedeutet
    Symbolbild, KI-generiert

    65.000 Euro Bußgeld für gekaufte Adressdaten: Was der Fall für jedes Unternehmen bedeutet

    Die Berliner Beauftragte für Datenschutz und Informationsfreiheit (BlnBDI) hat im Jahresbericht 2025 einen Fall veröffentlicht, der zeigt, wie teuer der sorglose Umgang mit fremden Adressdaten werden kann. Ein Berliner Kreisverband einer Partei erhielt im Bundestagswahlkampf 2021 zwei Chargen mit insgesamt 55.640 bzw. 77.540 Adressdatensätzen aus dem Melderegister, jeweils mit Familienname, Vorname, Doktorgrad und aktueller Anschrift. Rechtsgrundlage dafür war § 50 Abs. 1 Satz 1 Bundesmeldegesetz (BMG), der Meldebehörden erlaubt, Parteien vor Wahlen entsprechende Auskünfte zu erteilen. Dieses Recht gilt ausdrücklich nur für Parteien im Wahlkampf, kein Unternehmen kann sich darauf berufen.

    Der Fehler lag nicht im Bezug der Daten selbst, sondern in dem, was danach passierte. Der Kreisverband verschickte Anschreiben, in denen weder die eigene Identität als datenschutzrechtlich Verantwortlicher genannt wurde noch die übrigen Pflichtangaben nach Art. 14 DSGVO. Stattdessen wurde der Eindruck erweckt, die Schreiben stammten von bekannten Berliner Persönlichkeiten aus Politik und Wirtschaft, die zur Wahl des Bundestagskandidaten aufriefen (sogenannte Testimonials). Zusätzlich übergab der Kreisverband die Adressdaten an einen externen Dienstleister für Druck und Versand, ohne mit diesem eine Auftragsverarbeitungsvereinbarung nach Art. 28 DSGVO abzuschließen.

    Was rechtlich passiert: Die BlnBDI wertete die verschleierte Absenderidentität als Verstoß gegen das Transparenzgebot aus Art. 5 Abs. 1 lit. a DSGVO. Die fehlende Information der Betroffenen darüber, woher die Daten stammen, zu welchem Zweck sie verwendet werden und wer sie erhält, verstieß zusätzlich gegen Art. 14 DSGVO und erschwerte den Betroffenen die Ausübung ihrer Rechte. Beim Dienstleister kam ein dritter Fehler hinzu: Ohne Auftragsverarbeitungsvertrag fehlte die Weisungsbindung des Dienstleisters, ein wesentliches Merkmal jeder Auftragsverarbeitung nach Art. 28 Abs. 3 lit. a DSGVO. Die Behörde verhängte deshalb sechs Einzelbußgelder mit einer Gesamthöhe von 65.000 Euro. Strafverschärfend wertete sie die hohe Zahl Betroffener und die Täuschung durch die Testimonial-Gestaltung, strafmildernd die Kooperation des Kreisverbands und die verstrichene Zeit seit dem Verstoß.

    Auch jenseits von Parteien ein Thema: Die BMG-Regelung selbst ist ein Sonderrecht für Parteien vor Wahlen, kein allgemeiner Zugang für Unternehmen. Trotzdem sind die drei eigentlichen Fehler im Fall exakt die Fehler, die auch bei jedem gekauften oder überlassenen Adressdatensatz im gewerblichen Marketing drohen: fehlende Transparenz darüber, wer tatsächlich wirbt, fehlende Information über die Datenherkunft, und fehlender Auftragsverarbeitungsvertrag mit dem Dienstleister, der die Adressen für Druck, Versand oder Mailing-Kampagnen verarbeitet. Wer Adresslisten von einem Datenlieferanten oder Broker bezieht, muss zusätzlich prüfen, ob der Lieferant überhaupt eine Rechtsgrundlage hatte, die Daten weiterzugeben. Diese Prüfpflicht lässt sich nicht an den Lieferanten delegieren.

    Was die Behörde von Verantwortlichen erwartet: Wer mit fremden Adressdaten wirbt, muss vor dem ersten Versand drei Dinge klären: erstens die eigene Rechtsgrundlage für die Verarbeitung, zweitens die Informationspflichten nach Art. 14 DSGVO gegenüber den Betroffenen (woher stammen die Daten, wozu werden sie genutzt, wer bekommt sie), drittens einen Auftragsverarbeitungsvertrag mit jedem externen Dienstleister, der diese Daten im Auftrag verarbeitet, inklusive Weisungsbindung und Löschregelung nach Auftragsende.

    Für die Praxis heißt das: Eine gekaufte oder überlassene Adressliste ist kein rechtsfreier Raum, nur weil die Daten aus einem öffentlichen Register oder von einem Drittanbieter stammen. Wer plant, mit fremden Adressdaten zu werben, sollte vor dem ersten Versand prüfen, ob Rechtsgrundlage, Transparenzpflichten und Auftragsverarbeitungsvertrag tatsächlich vorliegen, nicht erst nach der ersten Beschwerde.


    Quelle: BlnBDI, Jahresbericht 2025, Abschnitt B-II-2, abgerufen am 08.07.2026 unter datenschutz-berlin.de/jahresbericht-2025/#B-II-2.

    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: 11.07.2026.

  • CVE-Flut 2026: Welche Sicherheitslücken bei NGINX, Apache & Co. Webseitenbetreiber wirklich betreffen
    Symbolbild, KI-generiert

    CVE-Flut 2026: Welche Sicherheitslücken bei NGINX, Apache & Co. Webseitenbetreiber wirklich betreffen

    Die Zahl gemeldeter Sicherheitslücken explodiert. Laut einem aktuellen Bericht von heise online („Lückenflut durch KI-Funde, Software-Hersteller schrauben an Patch-Strategien“) hat allein Microsoft an einem einzigen Patchday über 200 Sicherheitslücken geschlossen, viele davon von KI-Systemen aufgespürt. Bei Mozilla stieg die Zahl der gemeldeten Firefox-Lücken dank eines KI-Modells von 76 im März auf 423 im April. Mozilla veröffentlicht seither wöchentlich Sicherheitsupdates, auch Google beschleunigt seinen Update-Takt für Chrome.

    Was in den Schlagzeilen oft untergeht: Ein großer Teil dieser Meldungsflut besteht aus sehr kleinteiligen, automatisiert gefundenen Lücken in Nischen-Software, etwa den in letzter Zeit auffällig häufigen Massenmeldungen zu einfachen PHP-Skripten von Plattformen wie SourceCodester oder code-projects. Diese Lücken betreffen in aller Regel Bastel- und Lernprojekte, keine produktiven Business-Webseiten. Sie sind Rauschen, kein Signal.

    Das eigentlich Wichtige sind die Lücken in der Software, auf der ein Großteil des Internets tatsächlich läuft: Webserver, Middleware, Logging-Bibliotheken und Hosting-Panels. Genau diese haben wir für Sie geprüft und eingeordnet, mit Primärquellen-Beleg, ohne Panikmache, mit klarer Handlungsempfehlung.

    NGINX / NGINX Plus, mehrere Schwachstellen, teils kritisch

    • CVE-2026-42530, Use-after-free in ngx_http_v3_module (HTTP/3), hoch bis kritisch (CVSS v4 9.2), 1.31.0 bis 1.31.1, Fix 1.31.2+.
    • CVE-2026-42055, Pufferüberlauf in Proxy-v2/gRPC-Modul, 1.13.10 bis 1.31.1, Fix 1.31.2 / 1.30.3.
    • CVE-2026-9256, Pufferüberlauf in rewrite-Modul, 0.1.17 bis 1.31.0, Fix 1.31.1 / 1.30.2.
    • CVE-2026-42945 / -42946 / -40460, weitere Puffer-/HTTP-3-Adressspoofing-Probleme, Fix 1.31.0+/1.30.1+.
    • CVE-2026-48142 (Buffer-Overread charset-Modul), Fix 1.31.2+/1.30.3+.

    Was passiert: In mehreren Modulen (HTTP/3, Proxy/gRPC, URL-Rewriting) fehlen Längen-/Speicher-Grenzprüfungen; präparierte Anfragen/Header werden falsch verarbeitet.

    Was ist möglich: von Denial of Service (Worker-Absturz) bis theoretischer Codeausführung (Use-after-free CVE-2026-42530); i.d.R. unauthentifiziert, ohne Nutzerinteraktion.

    Wie behebt man es: Update auf 1.31.2 oder höher (Legacy 1.30.3+). HTTP/3, Proxy-HTTP/2 oder gRPC deaktivieren, falls nicht benötigt. Achtung bei ignore_invalid_headers off + large_client_header_buffers über 2 MB (erhöht Risiko bei CVE-2026-42055).

    Apache CXF, DoS durch unbegrenzte Attachment-Header

    Was passiert: CXF (Java-Framework für Web-Services) begrenzt die Anzahl der Attachment-Header eingehender Nachrichten nicht.

    Was ist möglich: Nachricht mit sehr vielen Headern, übermäßiger Speicher-/CPU-Verbrauch, DoS, unauthentifiziert.

    Wie behebt man es: Update auf 4.1.7 / 4.2.2 (Limit standardmäßig 500 pro Nachricht). Übergangsweise Header-Anzahl/Größe am Reverse Proxy begrenzen.

    Apache Tomcat / Tomcat Native, Konfig- und Auth-Schwächen

    • CVE-2026-55956 (moderat), Security-Constraints des Default-Servlets bei bestimmten HTTP-Methoden ignoriert.
    • CVE-2026-55276 (niedrig), geloggtes effektives web.xml zeigt Sicherheitskonfig unvollständig (reines Logging-Problem, Laufzeit-Rechte unberührt).
    • CVE-2026-55955 (niedrig), EncryptInterceptor nicht replay-geschützt.
    • aus 11.0.22: CVE-2026-43512 (Digest-Auth authentifiziert unbekannte Nutzer) / CVE-2026-43515 (Constraints falsch angewandt), beide moderat.

    Was passiert: überwiegend Zugriffskontroll-Logik plus ein Logging-Detail.

    Was ist möglich: Umgehung von Zugriffsbeschränkungen / falsche Authentifizierung, Zugang zu geschützten Bereichen.

    Wie behebt man es: Update auf 11.0.23 (bzw. aktuellste Patch-Version der genutzten 9.x/10.x/11.x-Reihe). Digest-Authenticator + EncryptInterceptor nach Update gezielt testen.

    Apache log4j, Log-Injection und stille Konfigurationsfehler

    • CVE-2026-34478, Log-Injection in Rfc5424Layout durch stille Umbenennung von newLineEscape; 2.21.0 bis 2.25.3, mittel (6.9), Fix 2.25.4.
    • CVE-2026-34480, stiller Log-Verlust in XmlLayout; 2.0-alpha1 bis 2.25.3, Fix 2.25.4.
    • CVE-2026-34479, analog in log4j-1.2-api-Brücke; 2.7 bis 2.25.3, Fix 2.25.4.

    Was passiert: newLineEscape (Zeilenumbruch-Escaping) wurde stillschweigend umbenannt; alte Attributnamen greifen nicht mehr.

    Was ist möglich: ohne Escaping CRLF-Einschleusung über geloggte Eingaben (Nutzername, User-Agent), gefälschte Log-Einträge (Log-Injection), täuscht SIEM / verschleiert Spuren.

    Wie behebt man es: Update auf 2.25.4; Konfigurationen mit Rfc5424Layout/XmlLayout/Log4j-1-Brücke auf aktuelle Attributnamen prüfen.

    cPanel / WHM, kritische Authentifizierungsumgehung (AKTIV AUSGENUTZT)

    Was passiert: CRLF-Injection im Login-/Session-Prozess, Authentifizierungsumgehung.

    Was ist möglich: unangemeldeter Angreifer erlangt Admin-Zugriff auf WHM/cPanel ohne Zugangsdaten, Kontrolle über den ganzen Hosting-Server samt aller Kundenwebseiten. Steht im CISA-Katalog aktiv ausgenutzter Lücken, real beobachtete Angriffe.

    Wie behebt man es: sofort cPanel-TSR einspielen (Auto-Update verifizieren), WHM-Port 2087 auf bekannte IPs/VPN beschränken, Login-Logs prüfen, beim Hoster nachfragen.

    GnuTLS, mehrere hochriskante TLS/DTLS-Lücken (Fix 3.8.13)

    • CVE-2026-33846 (hoch), Heap-Überschreibung bei DTLS-Fragmenten.
    • CVE-2026-33845 (hoch), Heap-Überlauf durch Unterlauf bei DTLS-Reassemblierung.
    • CVE-2026-42009 (hoch), undefiniertes Verhalten bei DTLS-Paketreihenfolge.
    • CVE-2026-42010 (hoch), Auth-Umgehung bei RSA-PSK durch NUL-Zeichen.
    • CVE-2026-42011/-42012/-42013 (mittel), Zertifikatsvalidierung (Name-Constraints, CN-Fallback bei überlangem SAN).

    Was passiert: GnuTLS (TLS/DTLS-Bibliothek, in Linux-Distros/Mailservern/VPNs); Lücken vor allem in DTLS-Verarbeitung plus Zertifikatsprüfung.

    Was ist möglich: Heap-Lücken, Speicherüberschreibung (schlimmstenfalls Codeausführung, wahrscheinlicher DoS); RSA-PSK-Auth-Umgehung; gefälschte/fremde Zertifikate als gültig durchgewunken.

    Wie behebt man es: Update auf GnuTLS 3.8.13 über Paketmanagement (apt/dnf/zypper); DTLS-/RSA-PSK-Nutzer (VPN-Gateways) priorisiert.

    CVE-2026-12746, Dancer2-OAuth-Plugin ohne CSRF-Schutz (state-Parameter)

    Was passiert: der OAuth-state-Parameter (CSRF-Schutz laut RFC 6749 Paragraf 10.12) fehlte vor 0.23.

    Was ist möglich: Angreifer kapert den OAuth-Login und verknüpft die Opfer-Sitzung mit eigenem OAuth-Konto, spätere Account-Übernahme ohne Passwort.

    Wie behebt man es: Update auf 0.23 oder höher (state wird generiert und geprüft); Modulversion im cpanfile auf 0.23+ fixieren.

    CVE-2026-12194, phpIPAM: authentifizierte Local File Inclusion

    Was passiert: über die API lassen sich Pfadangaben manipulieren, beliebige PHP-Dateien werden eingebunden/ausgeführt (LFI).

    Was ist möglich: Angreifer mit (auch niedrig privilegiertem) API-Zugriff führt PHP-Dateien aus, schlimmstenfalls Serverübernahme via Webshell.

    Wie behebt man es: Patch/Update einspielen; API deaktivieren wenn nicht benötigt; sonst API-Zugriff auf internes Netz/IP-Allowlist beschränken.

    Fazit / Handlungsempfehlung

    1. cPanel/WHM (CVE-2026-41940): höchste Prio, aktiv ausgenutzt, sofort patchen / beim Hoster nachfragen.
    2. NGINX/NGINX Plus: auf 1.31.2 (bzw. 1.30.3), besonders bei HTTP/3, Proxy-HTTP/2, gRPC.
    3. GnuTLS: Distributionsupdate auf 3.8.13, priorisiert bei DTLS/VPN.
    4. Apache Tomcat, CXF, log4j: nächstes Wartungsfenster auf aktuellste Version, Konfigs gegenprüfen.
    5. Dancer2-OAuth-Plugin, phpIPAM: nur falls im eigenen Stack im Einsatz, prüfen, dann patchen.

    Grundsätzlich: ein regelmäßiger, unabhängiger Sicherheits-Check der eigenen Webseite/Serverumgebung deckt genau solche Lücken auf, bevor sie zum Problem werden.

    Quellen (Abrufdatum: 10.07.2026)

    • KI-Flut: heise.de/news/Lueckenflut-durch-KI-Funde-Software-Hersteller-schrauben-an-Patch-Strategien-11360569.html
    • NGINX: nginx.org/en/security_advisories.html, github.com/advisories/GHSA-h78r-86c6-jgp4, my.f5.com/manage/s/article/K000161584
    • Apache CXF: nvd.nist.gov/vuln/detail/CVE-2026-50645, cxf.apache.org/security-advisories.html
    • Apache Tomcat: tomcat.apache.org/security-11.html
    • Apache log4j: logging.apache.org/security.html, nvd.nist.gov/vuln/detail/CVE-2026-34478
    • cPanel: nvd.nist.gov/vuln/detail/CVE-2026-41940, rapid7.com/blog/post/etr-cve-2026-41940-cpanel-whm-authentication-bypass/, CISA-KEV (aktive Ausnutzung)
    • GnuTLS: gnutls.org/security-new.html
    • Dancer2: metacpan.org/release/BIAFRA/Dancer2-Plugin-Auth-OAuth-0.23
    • phpIPAM: tenable.com/cve/CVE-2026-12194, securityvulnerability.io/vulnerability/CVE-2026-12194
  • FTC-Beben in den USA: Was das Slaughter-Urteil für Ihre US-Cloud-Nutzung bedeutet
    Symbolbild, KI-generiert

    FTC-Beben in den USA: Was das Slaughter-Urteil für Ihre US-Cloud-Nutzung bedeutet

    Am 29. Juni 2026 hat der US Supreme Court mit einer Entscheidung, die auf den ersten Blick wie ein rein amerikanisches Verfassungsthema wirkt, eine Frage neu aufgeworfen, die für deutsche Unternehmen mit US-Cloud-Diensten durchaus praktische Relevanz hat: Wie unabhängig ist die Aufsichtsbehörde, auf die sich die EU beim Datenschutz für Transfers in die USA verlässt?

    Dieser Beitrag ordnet ein, was tatsächlich entschieden wurde, was das für das EU-US Data Privacy Framework (DPF) bedeuten könnte und was daraus praktisch folgt. Bewusst nüchtern, ohne Alarmismus, aber auch ohne Beschönigung.

    Was ist am 29.06.2026 entschieden worden?

    Im Fall Trump v. Slaughter (Az. 25-332) hat der US Supreme Court mit 6 zu 3 Stimmen entschieden, dass die gesetzliche Regelung, wonach Mitglieder der Federal Trade Commission (FTC, die zentrale US-Wettbewerbs- und Verbraucherschutzbehörde) nur „for cause“, also nur aus wichtigem Grund wie Pflichtverletzung oder Untätigkeit, entlassen werden dürfen, gegen die Gewaltenteilung (die verfassungsrechtliche Trennung von Legislative, Exekutive und Judikative) verstößt.

    Damit hob das Gericht seine eigene, rund 91 Jahre alte Präzedenzentscheidung Humphrey’s Executor v. United States (1935) auf, die genau diesen Kündigungsschutz für Behördenmitglieder bislang für zulässig erklärt hatte.

    Hintergrund des Falls: Präsident Trump hatte am 18. März 2025 die beiden demokratischen FTC-Commissioner Rebecca Slaughter und Alvaro Bedoya entlassen, mit der Begründung, ihr Verbleib im Amt sei „inconsistent with the Administration’s priorities“ (nicht vereinbar mit den Prioritäten der Regierung), nicht mit einem der gesetzlich vorgesehenen Gründe. Nach einem längeren Instanzenzug (Wiedereinsetzung durch ein District Court im Juli 2025, mehrere Aussetzungsentscheidungen, Verfahren vor dem DC Circuit, vorläufiger Stopp durch den Supreme Court im September 2025) bestätigte der Supreme Court nun im Ergebnis: Der Präsident darf FTC-Commissioner künftig ohne wichtigen Grund entlassen.

    Klartext: Die FTC ist ab sofort de facto eine Behörde, deren Leitung jederzeit politisch ausgetauscht werden kann, so wie ein Ministerium. Das war seit 1935 bewusst anders geregelt, damit solche Aufsichtsbehörden unabhängig von der jeweiligen Regierung arbeiten können.

    Warum das für Ihre US-Cloud-Nutzung überhaupt relevant ist

    Auf den ersten Blick ein innenpolitisches US-Thema. Der Grund, warum es auch deutsche Geschäftsführer betrifft, liegt in einer Verbindung, die vielen nicht bewusst ist: Die FTC ist eine der zentralen Durchsetzungsbehörden hinter dem EU-US Data Privacy Framework (DPF), dem Angemessenheitsbeschluss der EU-Kommission vom Juli 2023 nach Art. 45 DSGVO, auf dessen Grundlage tausende Unternehmen personenbezogene Daten in die USA übermitteln, ohne für jeden Einzelfall zusätzliche Garantien (wie Standardvertragsklauseln, SCC) einholen zu müssen.

    Die EU-Kommission hatte bei der Angemessenheitsprüfung unter anderem darauf abgestellt, dass die FTC als unabhängige Aufsichtsbehörde funktioniert, unabhängig von tagespolitischer Einflussnahme. Recherchen zeigen, dass die EU-Kommission in ihrem Angemessenheitsbeschluss mehrfach, nach Angaben der Datenschutzorganisation noyb 259-mal, auf die als unabhängig beschriebene FTC Bezug nimmt.

    Annahme: Wenn FTC-Commissioner nun jederzeit ohne wichtigen Grund durch die Regierung entlassen werden können, sinkt die faktische Unabhängigkeit dieser Aufsichtsbehörde. Das ist keine Randnotiz, sondern rührt an einer der Grundannahmen, auf denen die Angemessenheit des DPF beruht.

    Was Beobachter dazu sagen, zwei Lesarten

    Wichtig für eine seriöse Einordnung: Es gibt zwei unterschiedliche Reaktionen auf das Urteil, die beide angeführt werden sollten.

    Die alarmierte Lesart: Die Datenschutzorganisation noyb (Max Schrems) erklärte am 29.06.2026, mit dem Urteil gebe es faktisch keine unabhängigen Aufsichtsbehörden mehr in den USA, und forderte die EU-Kommission auf, die Angemessenheitsentscheidung zum DPF geordnet aufzuheben. noyb kündigte zudem an, in den kommenden Wochen vor dem Gerichtshof der Europäischen Union (EuGH) gegen den Fortbestand des DPF vorzugehen. Auch die deutschen Wirtschaftsverbände BGA, DIHK und BDI warnten Anfang Juli 2026 vor wachsender Rechtsunsicherheit beim transatlantischen Datenverkehr.

    Die vorsichtigere Lesart: Die International Association of Privacy Professionals (IAPP) ordnet das Urteil zurückhaltender ein: Der Supreme Court habe die Frage, ob die Unabhängigkeit der „Adjudicators“ beziehungsweise „Inferior Officers“, konkret des Data Protection Review Court (DPRC), der eigenen Rechtsschutzinstanz innerhalb des DPF-Mechanismus, betroffen ist, ausdrücklich offengelassen. Das DPF selbst ist damit nicht automatisch hinfällig; die tatsächliche Rechtsfolge für den Angemessenheitsbeschluss ist derzeit ungeklärt, nicht bereits negativ entschieden.

    Einordnung: Beide Stimmen widersprechen sich nicht grundsätzlich, sie unterscheiden sich im Grad der Zuspitzung. Fest steht: Der Angemessenheitsbeschluss zum DPF ist zum jetzigen Zeitpunkt formal weiterhin in Kraft, Unternehmen, die unter dem DPF zertifiziert sind, dürfen weiterhin Daten übermitteln. Fest steht ebenfalls: Die EU-Kommission hat angekündigt zu prüfen, ob das Urteil Auswirkungen auf die Validität des DPF hat, und ein Verfahren vor dem EuGH ist von privater Seite bereits angekündigt. Wer schon einmal die Geschichte von Safe Harbor über Privacy Shield bis zum aktuellen DPF verfolgt hat (die sogenannte Schrems-II-Linie), erkennt hier ein bekanntes Muster: Ein US-Mechanismus wird von der EU-Kommission als angemessen anerkannt, gerät später wegen struktureller Fragen zur US-Aufsicht erneut unter juristischen Druck.

    Das Zwei-Ebenen-Problem: Papierform und Realität sind nicht dasselbe

    Bei ExpertoMundi arbeiten wir im Datenschutz-Audit regelmäßig mit einem Modell, das für die Einordnung dieses Urteils hilfreich ist, die Trennung zwischen zwei völlig unterschiedlichen Schutzebenen:

    Ebene 1, Haftungsschutz (Papierform): Ein Auftragsverarbeitungsvertrag (AVV) nach Art. 28 DSGVO kombiniert mit Standardvertragsklauseln (SCC) oder einer DPF-Zertifizierung schützt in erster Linie den Verantwortlichen, also das Unternehmen, das den US-Dienst einsetzt, vor Bußgeldern und Abmahnungen. Es ist eine rechtlich-formale Absicherung der Vertragsbeziehung.

    Ebene 2, Daten-Souveränität (Realität): Unabhängig von jeder Papierform bleibt die Tatsache bestehen, dass ein Unternehmen mit US-Konzernmutter der US-Jurisdiktion unterliegt. Über den US CLOUD Act oder § 702 FISA (Foreign Intelligence Surveillance Act, Rechtsgrundlage für die Erfassung von Kommunikation von Nicht-US-Personen außerhalb der USA durch US-Nachrichtendienste) kann US-Behörden faktisch Zugriff auf Daten gewährt werden, unabhängig davon, ob der Server physisch in Frankfurt steht oder ein AVV formal einwandfrei ist.

    Das Slaughter-Urteil ändert an Ebene 2 rechtlich nichts. Es ist aber ein Erinnerungspunkt: Wenn selbst die Aufsichtsbehörde, die die Papierform (Ebene 1) tragen soll, politisch weniger unabhängig wird, verliert genau dieses Argument, „es ist doch vertraglich alles geregelt“, an Substanz. Die Papierform schützt den Verantwortlichen, sie schützt nicht automatisch die Daten selbst.

    Was das praktisch bedeuten kann

    Kein Grund zur Panik, aber ein guter Anlass für eine Bestandsaufnahme. Folgende Schritte lassen sich unabhängig vom weiteren Verfahrensausgang schon jetzt sinnvoll angehen:

    • Bestandsaufnahme: Welche eingesetzten Cloud-/SaaS-Dienste haben eine US-Konzernmutter, auch wenn die Datenverarbeitung formal in der EU stattfindet? Ein vorhandener AVV allein beantwortet diese Frage nicht.
    • Transfer-Grundlage prüfen: Auf welcher Rechtsgrundlage nach Art. 44 ff. DSGVO beruht der jeweilige Datentransfer, DPF-Zertifizierung, SCC, oder beides? Diese Information findet sich meist im AVV oder in der Datenschutzerklärung des Anbieters.
    • Datenminimierung: Für besonders sensible Datenkategorien lohnt sich die Frage, ob überhaupt ein Transfer in die USA notwendig ist, oder ob eine EU-Alternative ohne US-Konzernmutter in der gesamten Kette (inklusive Sub-Unterauftragsverarbeiter) infrage kommt.
    • TOM (Technische und organisatorische Maßnahmen nach Art. 32 DSGVO): Verschlüsselung, bei der der Schlüssel ausschließlich beim europäischen Unternehmen liegt (etwa Double-Key-Encryption oder Customer-Key/BYOK-Modelle), reduziert die praktische Zugriffsmöglichkeit über den CLOUD Act unabhängig vom Ausgang des DPF-Verfahrens.
    • Entwicklung beobachten: Die angekündigte EuGH-Klage und eine mögliche Neubewertung durch die EU-Kommission können die Rechtslage in den kommenden Monaten verändern. Unternehmen mit umfangreicher US-Cloud-Nutzung können diese Entwicklung im Blick behalten, etwa über die Website der EU-Kommission zum Data Privacy Framework oder über Fachmedien.

    Wichtig ist die Reihenfolge: Erst die eigene Bestandsaufnahme, dann die Bewertung, ob und wo Handlungsbedarf besteht. Nicht jeder Einsatz eines US-Dienstes ist automatisch ein Risiko, die Einzelfallprüfung entscheidet.

    Fazit

    Das Slaughter-Urteil ist zunächst eine US-verfassungsrechtliche Entscheidung über die Reichweite präsidialer Entlassungsbefugnisse. Seine Tragweite für europäische Unternehmen liegt in der strukturellen Verbindung zwischen FTC-Unabhängigkeit und dem Angemessenheitsbeschluss zum EU-US Data Privacy Framework. Ob und wie sich das rechtlich auf den DPF-Fortbestand auswirkt, ist zum jetzigen Zeitpunkt (Stand 10.07.2026) offen und wird sowohl von der EU-Kommission als auch möglicherweise vom EuGH zu bewerten sein.

    Für die eigene Praxis bleibt die bekannte Lehre aus der Schrems-II-Historie gültig: Wer sich ausschließlich auf die formale Papierlage verlässt, hat einen Baustein, aber nicht die vollständige Antwort auf die Frage, wie sicher die eigenen Daten in einer US-Cloud tatsächlich sind.


    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: 10.07.2026.

    Quellen (Abrufdatum: 10.07.2026)

    • US Supreme Court: Trump v. Slaughter, No. 25-332, Urteil vom 29.06.2026, supremecourt.gov/opinions/25pdf/25-332_qn12.pdf
    • SCOTUSblog: „Supreme Court allows Trump to fire FTC commissioner and overturns major restraint on presidential power“, 29.06.2026, scotusblog.com
    • Congress.gov / Congressional Research Service: „Trump v. Slaughter and the Future of For-Cause Removal Protections“, CRS-Bericht LSB11448, congress.gov/crs-product/LSB11448
    • noyb (None of Your Business): „US Supreme Court just blew up EU-US Data Transfers“, 29.06.2026, noyb.eu
    • IAPP (International Association of Privacy Professionals): Einordnung Trump v. Slaughter und offene DPRC-Unabhängigkeitsfrage, 08.07.2026
    • dpa-Meldung „Wirtschaftsverbände warnen vor Risiken für Datenverkehr mit USA“, 09.07.2026 (u. a. finanznachrichten.de, ad-hoc-news.de); DIHK-Chefjustiziar Stephan Wernicke
  • Vom Gehirn zurück zum Transformer
    Symbolbild, KI-generiert

    Vom Gehirn zurück zum Transformer

    Es gibt eine verführerische Intuition über die Zukunft der KI: eine Leiter. Unten der Transformer, wie wir ihn heute kennen. In der Mitte irgendeine „gehirnähnliche“ Zwischenarchitektur. Ganz oben das menschliche Gehirn, der organische Supercomputer, der Zielpunkt, dem alles zustrebt. Ich will diese Leiter umdrehen. Denn wenn man vom Gehirn ausgeht und fragt, was man wegwerfen muss, um bei einem Transformer zu landen, versteht man heutige KI besser als aus jeder Fortschrittsbroschüre.

    Vorab zwei Korrekturen.

    Erstens der alte Mythos, wir nutzten nur einen Bruchteil unseres Gehirns. Das ist falsch. Bildgebung zeigt über den Tag praktisch flächendeckende Aktivität, Läsionen an fast jeder Stelle erzeugen Ausfälle, und das Organ verbraucht rund 20 % unserer Energie bei 2 % Körpermasse. 90 % Leerlauf hätte die Evolution nie toleriert. Es gibt keine schlafende Reserve zum Freischalten.

    Zweitens die „Zwischenstufe“. Einige KI-Startups vermarkten sich genau als diese mittlere Sprosse: gehirnähnliche, adaptive Architekturen, die angeblich auf dem Weg zu einer Art Bewusstsein sind, garniert mit Renditeversprechen und Investoren-Warteliste. Nur: Auf solchen Seiten steht selten ein einziger Mechanismus, der beschreibt, was technisch anders sein soll als bei einem Transformer. Eine „eigene neuronale Topologie“ zu behaupten ist kein Architekturbeleg, sondern ein Claim. Das ist typischerweise Investoren-Prosa, keine Zwischenstufe. Man sollte solche Bewusstseins-Versprechen mit derselben Skepsis lesen wie jeden Startup-Pitch, der gleichzeitig Kapital einwirbt.

    Zurück zur umgedrehten Leiter. Historisch ist der Transformer ohnehin nicht rückwärts aus dem Gehirn entwickelt worden, er stammt aus einer unbiologischen Linie: Matrixmathematik, Attention, GPU-Parallelität. Aber als Gedankenexperiment ist der Abstieg vom Gehirn zum Transformer erhellend. Man muss dafür sieben Achsen kappen:

    1. Spikes werden zu kontinuierlichen Werten. Neuronen feuern diskrete, zeitlich codierte, asynchrone Impulse. Der Transformer ersetzt sie durch kontinuierliche Aktivierungen in getakteter, synchroner Matrixmultiplikation. Die gesamte Zeitdimension des Codes verschwindet.
    2. Lokales Dauerlernen wird zu Backprop, dann eingefroren. Das Gehirn lernt online und lokal, immer. Der Transformer lernt per globaler Backpropagation und trennt Training von Inferenz, nach dem Training sind die Gewichte fix.
    3. Rekurrenz wird zu Feedforward. Das Gehirn ist massiv rückgekoppelt, mit Schleifen und anhaltender Dynamik. Der Transformer ist pro Token feedforward; Attention ist Routing, keine echte zeitliche Rekursion.
    4. Verkörperung wird zum Token-Strom. Das Gehirn steckt in einem Körper, in einer geschlossenen Wahrnehmungs-Handlungs-Schleife mit Echtzeit-Konsequenzen. Der Transformer bekommt eine statische Zeichenkette; die Welt wird zum Textkorpus.
    5. Heterogenität wird zu homogenen Einheiten. Dutzende Zelltypen, Neuromodulatoren, die ganze Schaltkreise umschalten. Beim Transformer: ein einziger, endlos wiederholter künstlicher Neuronentyp.
    6. Sparsam wird zu energiehungrig. Gehirn: rund 20 Watt, extrem sparse. Transformer: dichte Matrixmultiplikationen, Megawatt im Rechenzentrum.
    7. Evolutionspriors werden aus Daten gelernt. Das Gehirn startet mit angeborener Struktur. Der Transformer startet nahezu zufällig; sein Prior steckt in Architektur und Trainingsdaten, nicht in Jahrmillionen Evolution.

    Das Ergebnis dieser Kürzungen ist kein „früher Schritt Richtung Gehirn“. Es ist das Gehirn, radikal komprimiert, und zwar entlang exakt der Achsen, die sich mit heutiger Hardware und Gradientenabstieg überhaupt bauen lassen. Der Transformer ist die Version des Gehirns, die man in eine GPU zwängen kann.

    Dreht man die Liste wieder um, ergibt sich daraus eine ehrliche Landkarte für das, was als Nächstes kommt. Denn fast jede ernsthafte Forschungsrichtung ist der Versuch, eine dieser weggeworfenen Achsen wieder einzubauen. Neuromorphe und Spiking-Chips holen Impulse und Energieeffizienz zurück (Achse 1 und 6). Continual Learning greift das eingefrorene Gewicht an (2). State-Space-Modelle bringen echte Rekurrenz (3). Robotik und Weltmodelle bringen Verkörperung (4). Lokale Lernregeln attackieren die Backprop-Monokultur (2 und 5). Die „Zwischenstufe“ ist also kein mystischer Sprung zur Superintelligenz, sondern: Transformer plus schrittweise reingeholte Biologie.

    Bleibt ein ehrlicher Einwand gegen die Leiter selbst. Die Annahme, es gäbe eine Achse mit dem Gehirn als Zielpunkt, ist nicht gesichert. Flugzeuge sind keine rückwärts entwickelten Vögel, und sie fliegen schneller. Intelligenz muss nicht auf das menschliche Gehirn konvergieren; sie könnte in eine ganz andere Ecke des Möglichkeitsraums laufen, die auf keiner biologischen Achse liegt. Der Wert der umgedrehten Leiter liegt nicht darin, dass sie ein Ziel vorgibt. Er liegt darin, dass sie präzise zeigt, was der Transformer opfert, und das ist eine bessere Prognose-Grundlage als jedes Bewusstseins-Versprechen.

    Wer wissen will, wohin KI läuft, sollte also weniger fragen: „Wie nah sind wir am Gehirn?“, und mehr: „Welche der sieben Kürzungen holt die nächste Architektur zurück?“

  • Wenn der Nachlasspfleger zum „Empfänger“ wird: Was ein Schließfach-Irrtum über die DSGVO lehrt
    Symbolbild, KI-generiert

    Wenn der Nachlasspfleger zum „Empfänger“ wird: Was ein Schließfach-Irrtum über die DSGVO lehrt

    Eine Bank öffnet versehentlich das falsche Schließfach. Darin: Unterlagen samt Testament. Die Bank übergibt den Inhalt an einen Nachlasspfleger, ohne dass der eigentliche Mieter des Schließfachs davon erfährt. Als er es später merkt, will er wissen: Wer ist dieser Nachlasspfleger? Die Bank verweigert die Auskunft. Die saarländische Datenschutzaufsicht sieht das anders und spricht eine förmliche Warnung aus.

    Der Fall: falsches Schließfach, fremde Hand am Testament

    Laut dem 34. Tätigkeitsbericht des Unabhängigen Datenschutzzentrums Saarland (Landtagsdrucksache 17/1987, Kapitel 4.1) hatte eine Bank ein Schließfach geöffnet, das nicht geöffnet werden sollte. Den Inhalt, darunter ein Testament, gab sie an einen Nachlasspfleger weiter. Der eigentliche Mieter des Schließfachs bekam davon zunächst nichts mit.

    Als er es erfuhr, wollte er wissen, wer dieser Nachlasspfleger ist. Immerhin hatte diese Person Einblick in seine privatesten Unterlagen. Die Bank verweigerte die Auskunft und berief sich auf die Schutzinteressen des Nachlasspflegers.

    Ab wann ist jemand „Empfänger“ im Sinne der DSGVO?

    Die Aufsicht stellte sich auf die Seite des Betroffenen. Ihre Begründung: Der Nachlasspfleger wurde in dem Moment zum „Empfänger“ im Sinne von Art. 4 Nr. 9 DSGVO, in dem er die Unterlagen tatsächlich einsehen konnte. Ob er die Daten anschließend selbst weiterverarbeitet oder speichert, spielt keine Rolle. Die bloße Möglichkeit der Kenntnisnahme reicht.

    Gestützt wird diese Lesart auf ein aktuelles EuGH-Urteil zum Dateisystembegriff (C-740/22, Urteil vom 07.03.2024). Danach gilt die DSGVO bereits, sobald personenbezogene Daten in einem „Dateisystem“ gespeichert sind oder gespeichert werden sollen. Digital oder rein analog in Papierakten, das macht keinen Unterschied. Genauso wenig, ob die Offenlegung mündlich, per Papierunterlagen oder technisch erfolgt.

    Für Unternehmen mit gemischten Prozessen, Papierakte neben Datenbank, ist das eine klare Ansage: Der Auskunftsanspruch endet nicht an der Aktenschrank-Tür. Wer personenbezogene Daten weitergibt, egal in welcher Form, muss damit rechnen, dass diese Weitergabe auskunftspflichtig wird.

    Die Bank gab nach, ohne die Rechtsauffassung zu teilen

    Am Ende kam die Bank der Auskunftsanordnung nach, allerdings „ohne Anerkennung einer Rechtspflicht“. Die Aufsicht sprach trotzdem eine förmliche Warnung nach Art. 58 Abs. 2 lit. a DSGVO aus. Der Grund: Die Bank teilte die Rechtsauffassung der Aufsicht inhaltlich nicht. Eine Warnung nach dieser Vorschrift ist kein Bußgeld, aber ein amtlicher Vermerk, dass ein Verstoß vorlag.

    Was heißt das für Sie?

    Annahme, über die reine Berichtslage hinaus: Der Fall betrifft konkret die Kreditwirtschaft und einen physischen Datenträger, ein Schließfach. Der zugrunde liegende Rechtsgedanke, wer Zugriff auf personenbezogene Daten bekommt, wird zum Empfänger, unabhängig vom Medium, ist aber allgemein formuliert. Eine höchstrichterliche Bestätigung genau dieser Übertragung auf andere Branchen gibt es nicht. Es handelt sich um eine aufsichtsbehördliche Einzelfallentscheidung, keine Leitentscheidung eines obersten Gerichts.

    Wenn Ihr Unternehmen mit sensiblen Kundenunterlagen arbeitet, digital oder auf Papier, ergeben sich daraus zwei Prüfpunkte:

    1. Wissen Sie jederzeit, wer intern oder extern Zugriff auf welche Kundenunterlagen bekommen hat? Ein interner Fehler wie eine Verwechslung befreit nicht von der Pflicht, die Weitergabe dokumentieren und auf Anfrage offenlegen zu können.
    2. Ist Ihr Auskunftsprozess auf physische Datenträger vorbereitet? Papierakten, Schließfächer, Aktenschränke, gehören genauso zum Anwendungsbereich der DSGVO wie Datenbanken.

    Fazit

    Ein einzelner Verwechslungsfehler an einem Schließfach reichte aus, um die Bank in eine aufsichtsbehördliche Warnung zu bringen. Nicht weil die Verwechslung selbst das Problem war, sondern weil die Bank anschließend die Auskunft über den Empfänger verweigerte. Wer personenbezogene Daten weitergibt, auf Papier oder digital, sollte wissen: Der Empfänger-Begriff der DSGVO greift, sobald tatsächliche Kenntnisnahme möglich war. Nicht erst, wenn die Daten aktiv weiterverarbeitet wurden.

    Quellen

    • Primärquelle: Unabhängiges Datenschutzzentrum Saarland — 34. Tätigkeitsbericht Datenschutz 2025 (Landtagsdrucksache 17/1987, vorgelegt am 18.03.2026), Kapitel 4.1 „Das Auskunftsrecht in der Kreditwirtschaft“, Abschnitt „Auskunft über Datenempfänger nach irrtümlicher Schließfachöffnung“ (S. 47–52). Zum PDF des Berichts
    • Art. 4 Nr. 9 DSGVO (Empfänger-Definition) — Volltext: DSGVO Art. 4 im Wiki
    • Art. 58 Abs. 2 lit. a DSGVO (Aufsichtsbefugnisse, Warnung) — Volltext: DSGVO Art. 58 im Wiki
    • EuGH, Urteil vom 07.03.2024, C-740/22 (Dateisystembegriff, digital wie analog).

    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: 07.07.2026.

  • Darf ich wissen, welcher Bank-Mitarbeiter mein Konto angesehen hat? Was Art. 15 DSGVO wirklich hergibt
    Symbolbild, KI-generiert

    Darf ich wissen, welcher Bank-Mitarbeiter mein Konto angesehen hat? Was Art. 15 DSGVO wirklich hergibt

    Ein Bankkunde wollte wissen, welche Mitarbeitenden in den letzten Jahren auf sein Konto zugegriffen haben. Die Bank verlangte zuerst einen „belastbaren Verdacht“ mit Namen und Zeitraum. Die saarländische Datenschutzaufsicht sah das anders. Der Fall aus dem aktuellen 34. Tätigkeitsbericht 2025 zeigt: Auch Sie als Verantwortlicher können durch Ihr eigenes Zugriffsprotokoll auskunftspflichtig werden. Und das betrifft nicht nur Banken.

    Ein Kunde, ein Konto, ein Verdacht

    Ein Bankkunde beantragte Auskunft nach Art. 15 DSGVO. Nicht nur allgemein, welche Daten zu seiner Person gespeichert sind. Er wollte konkret wissen, welche Mitarbeitenden der Bank in den letzten Jahren auf sein Konto zugegriffen hatten. Sein Verdacht: unberechtigte Zugriffe.

    Die Bank stellte eine Gegenforderung. Auskunft nur, wenn der Kunde Namen und Zeitraum des angeblich unrechtmäßigen Zugriffs konkret benennen könne. Der Kunde blieb dabei: Sein Auskunftsanspruch umfasse auch die Protokolldaten, aus denen die Kontozugriffe hervorgehen. Er beschwerte sich, als die Bank ohne Namensnennung keine Auskunft geben wollte.

    Das Unabhängige Datenschutzzentrum Saarland hat den Fall in seinem 34. Tätigkeitsbericht 2025 entschieden (Kapitel 4.1, Abschnitt „Auskunft über Zugriffe durch Mitarbeitende“). Und der Bank widersprochen.

    Mitarbeitende sind normalerweise kein „Empfänger“

    Der zentrale Anknüpfungspunkt: Art. 15 Abs. 1 lit. c DSGVO, das Recht auf Auskunft über die Empfänger, gegenüber denen personenbezogene Daten offengelegt wurden. Die Aufsicht stellt klar, gestützt auf ein EuGH-Urteil zum Empfängerbegriff: Mitarbeitende einer verantwortlichen Stelle sind in der Regel kein „Empfänger“ im Sinne des Art. 4 Nr. 9 DSGVO. Vorausgesetzt, sie verarbeiten die Daten unter Aufsicht und nach Weisung. Der ganz normale, weisungsgemäße Blick einer Bank-Mitarbeiterin auf ein Kundenkonto begründet also für sich genommen noch keinen Anspruch, ihre Identität zu erfahren.

    Die Ausnahme: Sobald ein Mitarbeitender in einem sogenannten Mitarbeiterexzess handelt, also rechtswidrig oder außerhalb der internen Regularien auf Kundendaten zugreift, kann Auskunft über die konkrete Identität geschuldet sein. Und erfährt der Verantwortliche davon, ist er ohnehin nach Art. 33 DSGVO meldepflichtig.

    Muss der Kunde seinen Verdacht belegen?

    Das ist der Kernpunkt des Falls. Die Bank wollte Namen und Zeitraum, bevor sie überhaupt weitere Auskunft erteilt. Die Aufsicht hat das zurückgewiesen: Diese Informationen liegen dem Betroffenen in aller Regel gar nicht vor. Er kann sie schlicht nicht liefern. Es reicht, dass er Umstände darlegt, die einen weisungswidrigen Zugriff denkbar erscheinen lassen. Ab da dreht sich die Pflicht um. Jetzt muss der Verantwortliche intern aufklären, ob ein Mitarbeiterexzess vorlag.

    Protokolldaten sind personenbezogene Daten. Auch wenn sie Zugriffe protokollieren

    Der zweite Baustein betrifft die Kopie nach Art. 15 Abs. 3 DSGVO. Der Begriff des personenbezogenen Datums (Art. 4 Nr. 1 DSGVO) ist weit gefasst. Deshalb sind auch technische Zugriffsprotokolle, die festhalten, wer wann auf ein Kundenkonto zugegriffen hat, personenbezogene Daten des Kontoinhabers. Nicht nur der protokollierten Mitarbeitenden. Sie unterliegen also grundsätzlich dem Kopieanspruch.

    Art. 15 Abs. 4 DSGVO erlaubt zwar, Mitarbeiternamen in den Protokollen zu schwärzen, wenn das zum Schutz der protokollierten Personen nötig ist. Aber nur nach echter Einzelfall-Abwägung, nicht pauschal. Die Aufsicht liefert ein griffiges Kriterium: Wer im Mitarbeiterexzess gehandelt hat, muss ohnehin namentlich benannt werden (Art. 15 Abs. 1 lit. c DSGVO) und hat dann auch kein schutzwürdiges Interesse mehr, geschwärzt zu werden. Wer dagegen ganz normal im Kundenkontakt tätig war und weisungsgemäß zugegriffen hat, hat ein stärkeres Schutzinteresse an der Schwärzung.

    Zur Einordnung: Das Verfahren war laut Bericht zum Ende des Berichtszeitraums noch nicht abgeschlossen. Es handelt sich um eine aufsichtsbehördliche Rechtsauffassung (Hinweis nach Art. 58 Abs. 1 lit. d DSGVO), nicht um eine rechtskräftige gerichtliche Entscheidung.

    Was heißt das für Sie?

    Annahme, über die reine Berichtslage hinaus: Der Fall betrifft konkret die Kreditwirtschaft. Aber die Wertung dahinter, Mitarbeitende sind nur bei Exzess namentlich auskunftspflichtig, Zugriffsprotokolle sind kopiepflichtige Daten des Betroffenen, ist branchenneutral formuliert. Sie dürfte grundsätzlich auf jeden Verantwortlichen mit Nutzer-, Kunden- oder Patientenkonten und internem Zugriffslog übertragbar sein: Arztpraxis-Software, CRM-Systeme, Kundenportale. Eine höchstrichterliche Bestätigung für diese Übertragung gibt es nicht. Es bleibt eine aufsichtsbehördliche Einzelfallentscheidung, keine Leitentscheidung eines obersten Gerichts.

    Wenn Sie eine Kundendatenbank, ein Praxisverwaltungssystem oder ein CRM betreiben, ergeben sich daraus zwei Prüfpunkte:

    1. Können Sie im Ernstfall überhaupt nachweisen, wer wann auf einen bestimmten Kundendatensatz zugegriffen hat? Ohne Zugriffsprotokollierung auf Datensatz-Ebene können Sie weder einen Mitarbeiterexzess ausschließen noch eine Auskunftsanfrage rechtssicher beantworten.
    2. Haben Sie einen Prozess, um einen „denkbar erscheinenden“ Verdacht intern aufzuklären? Statt vom Betroffenen einen belegten Verdacht mit Namen zu verlangen. Genau das hat die Aufsicht der Bank hier untersagt.

    Fazit

    Art. 15 DSGVO reicht weiter, als viele denken. Er endet nicht bei der Frage, welche Daten Sie über jemanden speichern. Er erstreckt sich unter Umständen auch darauf, wer aus Ihrem eigenen Haus wann auf diese Daten zugegriffen hat. Wer kein sauberes Zugriffsprotokoll führt und keinen internen Aufklärungsprozess für Verdachtsfälle hat, landet schnell in genau der Situation wie die Bank hier: eine aufsichtsbehördliche Beanstandung, weil man dem Betroffenen zu viel abverlangt hat.

    Quellen

    • Primärquelle: Unabhängiges Datenschutzzentrum Saarland — 34. Tätigkeitsbericht Datenschutz 2025 (Landtagsdrucksache 17/1987, vorgelegt am 18.03.2026), Kapitel 4.1 „Das Auskunftsrecht in der Kreditwirtschaft“, Abschnitt „Auskunft über Zugriffe durch Mitarbeitende“ (S. 52–55). Zum PDF des Berichts
    • Art. 15 DSGVO (Auskunftsrecht der betroffenen Person) — Volltext: dsgvo-gesetz.de/art-15-dsgvo
    • Art. 4 Nr. 9 DSGVO (Empfänger-Definition) — Volltext: dsgvo-gesetz.de/art-4-dsgvo
    • Im Bericht zitiert (zur Einordnung): EuGH, Urteil vom 22.06.2023, C-579/21 (Empfängerbegriff); EuGH, Urteil vom 12.01.2023, C-154/21 (Zweck des Auskunftsrechts).

    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: 06.07.2026.

  • Deutsche Wohnen zahlt 900.000 Euro DSGVO-Bußgeld, weil niemand die Löschroutine gepflegt hat
    Symbolbild, KI-generiert

    Deutsche Wohnen zahlt 900.000 Euro DSGVO-Bußgeld, weil niemand die Löschroutine gepflegt hat

    Das Landgericht Berlin I hat das ursprünglich 14,5 Millionen Euro hohe DSGVO-Bußgeld gegen die Deutsche Wohnen SE auf 900.000 Euro reduziert. Am Verstoss selbst ändert das nichts. Das Unternehmen hatte über Jahre keine funktionierende Löschroutine für Mieterdaten wie Gehaltsabrechnungen, Kontoauszüge und Ausweisdokumente. Das Urteil zeigt, worauf es bei Aufsichtsbehörden wirklich ankommt: nicht guter Wille, sondern belegbare Prozesse.

    Was das Landgericht entschieden hat

    Die 26. Große Strafkammer (Bußgeldkammer) des Landgerichts Berlin I hat am 9. Juni 2026 im Verfahren 526 OWi LG 1/20 ein Urteil gefällt. Deutsche Wohnen hatte im Zeitraum vom 25. Mai 2018 bis zum 5. März 2019 personenbezogene Daten von Mietern gespeichert, ohne fristgerecht zu löschen. Betroffen waren Gehaltsabrechnungen, Kontoauszüge und Ausweisdokumente, teils aus abgeschlossenen Mietverhältnissen. Die Grundlage fehlte: ein Löschkonzept, das im Alltag tatsächlich greift.

    Das Gericht bestätigt den DSGVO-Verstoss in vollem Umfang. Der Tenor stützt sich primär auf Artikel 5 Absatz 1 lit. c und lit. e DSGVO, Datenminimierung und Speicherbegrenzung, in Verbindung mit Artikel 6 Absatz 1 DSGVO, also der fehlenden Rechtsgrundlage für die weitere Speicherung. Einordnend dahinter steht die Löschpflicht aus Artikel 17, und was praktisch fehlte, war eine funktionierende technische und organisatorische Massnahme im Sinne von Artikel 32, mit der sich Löschfristen im Datenbestand überhaupt hätten durchsetzen lassen. Beim Bußgeld selbst zeigt sich das Gericht milder als die Aufsichtsbehörde 2019. Von 14,5 Millionen Euro bleiben 900.000 Euro übrig.

    Drei Gründe hat das Gericht dafür genannt. Deutsche Wohnen hatte externe Prüfer und IT-Experten eingebunden, um das Problem zu lösen, das zählt als aktives Bemühen. Der Verstoss fiel in die frühe Phase der DSGVO-Anwendung, als viele Unternehmen noch mit der Umsetzung rangen. Und die Aufsichtsbehörde selbst hatte Dokumentationslücken, die eine höhere Strafe schwerer begründbar machten. Das Urteil ist noch nicht rechtskräftig, eine Rechtsbeschwerde ist möglich.

    Was diese Entscheidung wirklich zeigt

    Der Fall wird oft als Entwarnung gelesen, weil die Zahl kleiner wurde. Das ist der falsche Schluss. Der Verstoss stand fest, bevor über die Höhe verhandelt wurde. Ein Unternehmen mit Millionen-IT-Budget und eigener Rechtsabteilung ist an einer Löschroutine gescheitert, die auf dem Papier in jedem Datenschutzkonzept steht.

    Das Muster ist bekannt. Firmen investieren in Berater, Zertifikate und Datenschutzerklärungen, aber niemand prüft, ob alte Kundendaten nach Ablauf der Aufbewahrungsfrist tatsächlich gelöscht werden. Genau da hakt es in der Praxis am häufigsten, nicht bei der Einwilligung auf der Webseite, sondern bei dem, was mit den Daten passiert, nachdem der Vertrag längst beendet ist.

    Mildernd wirkte am Ende, dass Deutsche Wohnen externe Expertise eingebunden hatte. Das ist die eigentliche Lehre für jedes Unternehmen: Aufsichtsbehörden und Gerichte bewerten, ob ein belastbarer Prozess existiert und dokumentiert nachvollzogen werden kann. Eine Absichtserklärung reicht nicht, ein gepflegtes Löschkonzept mit Fristen, Zuständigkeiten und Nachweisen schon eher.

    Was das für Ihre Webseite und Ihr Unternehmen bedeutet

    Wer glaubt, ein Cookie-Banner und eine Datenschutzerklärung würden ausreichen, unterschätzt genau den Bereich, an dem Deutsche Wohnen gescheitert ist. Löschkonzept und technisch-organisatorische Massnahmen sind kein Compliance-Beiwerk, sie sind der Teil, den Aufsichtsbehörden bei einer Prüfung als Erstes verlangen. Und sie sind der Teil, der in den meisten kleinen und mittleren Unternehmen überhaupt nicht existiert.

    Die relevante Frage lautet nicht, ob ein Datenschutzhinweis auf der Webseite steht. Sie lautet, ob personenbezogene Daten nach Ablauf der gesetzlichen oder vertraglichen Frist tatsächlich gelöscht werden, und ob sich das im Zweifel belegen lässt.

    Unser Auditor prüft genau diese Punkte vor Livegang einer Webseite oder im laufenden Betrieb: Löschkonzept, Speicherbegrenzung, technische und organisatorische Massnahmen, dazu über 60 weitere Prüfpunkte aus DSGVO, TMG und aktueller Rechtsprechung. Das Ergebnis liegt in zwei Sichten vor, eine für die Geschäftsführung mit Risikoeinschätzung, eine für die technische Umsetzung mit konkreten Fixes.

    Quellen

    Landgericht Berlin I, 26. Große Strafkammer (Bußgeldkammer), Urteil vom 9. Juni 2026, Aktenzeichen 526 OWi LG 1/20 (nicht rechtskraeftig, Rechtsbeschwerde moeglich). Datenschutz-Grundverordnung (DSGVO), Artikel 5 Absatz 1 Buchstabe c und Buchstabe e (Datenminimierung, Speicherbegrenzung), Artikel 6 Absatz 1 (Rechtmaeßigkeit der Verarbeitung), Artikel 17 (Recht auf Loeschung), Artikel 32 (Sicherheit der Verarbeitung), dsgvo-gesetz.de.

    Disclaimer

    Dieser Beitrag ordnet eine aktuelle, noch nicht rechtskräftige Gerichtsentscheidung allgemein ein und stellt keine Rechtsberatung im Sinne des Rechtsdienstleistungsgesetzes dar. Für eine rechtliche Bewertung des Einzelfalls wenden Sie sich an eine Rechtsanwältin oder einen Rechtsanwalt.

  • NIS2-Registrierung beim BSI: Frist abgelaufen. Muss sich Ihr Unternehmen registrieren?
    Symbolbild, KI-generiert

    NIS2-Registrierung beim BSI: Frist abgelaufen. Muss sich Ihr Unternehmen registrieren?

    Stand der Korrektur 06.11.2026: Die Registrierungsfrist und die Größenschwelle nach § 28 BSIG sind richtiggestellt, der 31. Juli 2026 war keine gesetzliche Frist; präzisiert ist, woher die 18 Sektoren stammen und seit wann die Risikomanagement-Pflichten gelten.

    Kurz gefasst: Wer in Deutschland zu einer der 18 NIS2-relevanten Branchen gehört und mindestens 50 Mitarbeitende oder mehr als 10 Millionen Euro Jahresumsatz bei zugleich mehr als 10 Millionen Euro Jahresbilanzsumme hat, muss sich beim Bundesamt für Sicherheit in der Informationstechnik (BSI) registrieren. Die gesetzliche Frist dafür beträgt drei Monate und ist für die meisten Unternehmen im März 2026 abgelaufen. Betroffen sind schätzungsweise 29.000 bis 30.000 Unternehmen in Deutschland – deutlich mehr als bislang unter dem alten IT-Sicherheitsgesetz.

    Für Geschäftsführerinnen und Geschäftsführer: Was heißt das konkret?

    Drei Fragen, die Sie sich jetzt stellen sollten:

    1. Sind wir betroffen? Prüfen Sie Branche und Unternehmensgröße anhand der Kriterien weiter unten – in wenigen Minuten erledigt.
    2. Was kostet uns Nichtstun? Bußgelder bis 10 Millionen Euro, persönliche Haftungsrisiken für die Geschäftsleitung und im Ernstfall ein Sicherheitsvorfall ohne funktionierenden Notfallplan.
    3. Wie viel Zeit bleibt? Die gesetzliche Registrierungsfrist ist für die meisten Unternehmen im März 2026 abgelaufen. Wer erst später unter NIS2 fällt, etwa durch Wachstum oder ein neues Geschäftsfeld, hat ab diesem Zeitpunkt drei Monate. Die Risikomanagement-Pflichten gelten seit dem 6. Dezember 2025 ohne Übergangsfrist, und ihre Umsetzung braucht Zeit – warten Sie damit nicht länger.

    Der Rest dieses Beitrags liefert die Details für die Umsetzung – sowohl für die Geschäftsführung als auch für IT-Verantwortliche.

    Was ist NIS2 – und warum jetzt?

    Die NIS2-Richtlinie ist eine EU-weite Vorgabe zur Cybersicherheit kritischer und wichtiger Einrichtungen. Deutschland hat sie mit dem NIS2-Umsetzungs- und Cybersicherheitsstärkungsgesetz (NIS2UmsuCG) am 6. Dezember 2025 in Kraft gesetzt – ohne Übergangsfrist. Die ursprüngliche Registrierungsfrist beim BSI lief bereits im März 2026 ab. Bis dahin hatte sich nur ein Teil der betroffenen Unternehmen registriert. Der 31. Juli 2026, der danach vielfach als Nachfrist genannt wurde, war keine gesetzliche Frist. Berichten zufolge wollte das BSI verspätete Registrierungen bis zu diesem Tag dulden; amtlich veröffentlicht hat es dazu nichts, auf seiner Themenseite steht nur: „Die gesetzliche Registrierungsfrist ist bereits abgelaufen.“ Wer sich nicht oder nicht rechtzeitig registriert, riskiert ein Bußgeld von bis zu 500.000 Euro (§ 65 BSIG).

    Für Geschäftsführerinnen und Geschäftsführer heißt das: Die Frage „betrifft uns das überhaupt?“ muss jetzt beantwortet sein – nicht erst, wenn eine Behörde nachfragt.

    Selbst-Check: Sind Sie betroffen?

    Die NIS2-Richtlinie nennt 18 Sektoren in zwei Anhängen; das deutsche BSI-Gesetz fasst sie in seinen Anlagen 1 und 2 zu je sieben Sektoren zusammen und regelt die Bundesverwaltung gesondert (§ 29 BSIG):

    • Anhang 1 (besonders kritisch): Energie, Transport, Bankwesen, Finanzmarktinfrastruktur, Gesundheitswesen, Trinkwasser, Abwasser, digitale Infrastruktur, IKT-Dienstleistungsmanagement, öffentliche Verwaltung, Weltraum
    • Anhang 2 (kritisch): Post- und Kurierdienste, Abfallwirtschaft, Chemikalienproduktion, Lebensmittelproduktion und -vertrieb, verarbeitendes Gewerbe, Anbieter digitaler Dienste, Forschung

    Innerhalb dieser Sektoren gilt die Pflicht ab folgenden Schwellenwerten:

    • mindestens 50 Beschäftigte oder
    • mehr als 10 Millionen Euro Jahresumsatz und mehr als 10 Millionen Euro Jahresbilanzsumme (bei beiden Schwellen zählen Zahlen verbundener Unternehmen und anteilig die von Partnerunternehmen grundsätzlich mit)

    Die Einstufung erfolgt in zwei Stufen: besonders wichtige Einrichtungen (Anhang-1-Sektoren mit mindestens 250 Beschäftigten oder über 50 Millionen Euro Umsatz bei gleichzeitig über 43 Millionen Euro Bilanzsumme) und wichtige Einrichtungen (alle übrigen Unternehmen oberhalb der Schwellenwerte). Die Selbsteinschätzung ist Pflicht des Unternehmens – das BSI prüft nicht von sich aus vorab, ob Sie betroffen sind.

    Praxis-Tipp: Wenn Sie unsicher sind, ob Ihr Unternehmen unter einen der 18 Sektoren fällt, lohnt sich ein Blick auf den offiziellen BSI-Selbstcheck sowie eine kurze Rücksprache mit Ihrem IT-Dienstleister oder Datenschutzbeauftragten – besser einmal zu viel geprüft als eine Frist verpasst.

    Auch mittelbar Betroffene sollten aufmerksam werden: Wer als Zulieferer, IT-Dienstleister oder Software-Anbieter für ein NIS2-pflichtiges Unternehmen arbeitet, wird über die Lieferketten-Sicherheitspflicht (siehe unten) faktisch mit in die Verantwortung genommen – auch ohne selbst unmittelbar registrierungspflichtig zu sein. Größere Auftraggeber werden in den kommenden Monaten vermehrt Sicherheitsnachweise von ihren Zulieferern einfordern.

    Was ist konkret zu tun?

    1. Registrierung beim BSI

    Die Registrierung erfolgt über das BSI-Melde- und Informationsportal (MIP). Erforderlich sind unter anderem Kontaktdaten, Sektor-Zuordnung, Unternehmensgröße und eine Selbsteinschätzung der Einrichtungskategorie.

    2. Zehn Risikomanagement-Bereiche umsetzen

    Das NIS2UmsuCG verlangt technische und organisatorische Maßnahmen in zehn Bereichen, darunter:

    • Konzepte für Risikoanalyse und Sicherheit der Informationssysteme
    • Bewältigung von Sicherheitsvorfällen (Incident Response)
    • Aufrechterhaltung des Betriebs, Backup-Management und Krisenmanagement
    • Sicherheit der Lieferkette (Lieferanten- und Dienstleisterprüfung)
    • Sicherheit bei Erwerb, Entwicklung und Wartung von IT-Systemen
    • Bewertung der Wirksamkeit von Risikomanagement-Maßnahmen
    • Basis-Konzepte für Cyberhygiene und Schulungen
    • Konzepte zu Kryptografie und Verschlüsselung
    • Personalsicherheit, Zugriffskontrolle und Anlagenmanagement
    • Verwendung von Mehr-Faktor-Authentifizierung (MFA) und gesicherter Kommunikation

    3. Meldepflichten bei Sicherheitsvorfällen

    Bei erheblichen Sicherheitsvorfällen gilt ein gestuftes Meldeverfahren gegenüber dem BSI: eine Frühwarnung innerhalb von 24 Stunden, eine vollständigere Meldung innerhalb von 72 Stunden sowie ein Abschlussbericht spätestens einen Monat später. Wer hierfür keinen Prozess hat, muss ihn jetzt aufbauen – im Ernstfall zählt jede Stunde.

    Fristen und Bußgelder im Überblick

    WasTermin / Höhe
    Registrierungsfrist BSIdrei Monate ab Eintritt der Pflicht (§ 33 Abs. 1 BSIG), für die meisten Unternehmen im März 2026 abgelaufen
    Bußgeld besonders wichtige Einrichtungenbis 10 Mio. Euro oder 2 % des weltweiten Jahresumsatzes (je nachdem, was höher ist)
    Bußgeld wichtige Einrichtungenbis 7 Mio. Euro oder 1,4 % des weltweiten Jahresumsatzes

    Zusätzlich zum Bußgeldrisiko drohen bei Pflichtverletzungen persönliche Haftungsfragen für die Geschäftsleitung sowie – im Fall eines tatsächlichen Sicherheitsvorfalls ohne funktionierendes Risikomanagement – Betriebsunterbrechungen, Reputationsschäden und Folgekosten, die weit über das Bußgeld hinausgehen können.

    Für Technik-Verantwortliche heißt das konkret: Die zehn Risikomanagement-Bereiche sind keine einmalige Dokumentationsübung, sondern verlangen belastbare, wiederholt geprüfte Prozesse – insbesondere MFA-Rollout, Backup-Tests und ein dokumentiertes Lieferketten-Screening sind häufig die Punkte, die in der Praxis am längsten dauern.

    Wie ein Website- und Security-Audit bei der NIS2-Vorbereitung hilft

    NIS2 betrifft nicht nur interne Netzwerke und Server – auch die eigene Website und die darüber laufenden Datenflüsse gehören zur Angriffsfläche eines Unternehmens. Ein strukturierter Blick von außen zeigt häufig schnell, wo Nachholbedarf besteht: veraltete Verschlüsselung, ungesicherte Formulare, fehlende Zugriffskontrollen im Content-Management-System oder unklare Verantwortlichkeiten bei Drittanbieter-Einbindungen.

    Wir bei Experto Mundi prüfen im Rahmen unserer Website- und Datenschutz-Audits genau solche Schwachstellen – als einen von mehreren Bausteinen auf dem Weg zur NIS2-Konformität. Ein Audit ersetzt keine vollständige NIS2-Umsetzung, kann aber ein guter erster Schritt sein, um zu sehen, wo Ihr Unternehmen heute steht.

    Quellen

    Bundesamt fuer Sicherheit in der Informationstechnik (BSI), Melde- und Informationsportal (MIP), Informationsseite zur NIS2-Registrierung („Die gesetzliche Registrierungsfrist ist bereits abgelaufen.“, abgerufen am 06.11.2026); § 28 Abs. 2 und § 33 Abs. 1 BSIG (gesetze-im-internet.de, abgerufen am 06.11.2026). Gesetz zur Umsetzung der NIS-2-Richtlinie und zur Regelung wesentlicher Grundzuege des Informationssicherheitsmanagements in der Bundesverwaltung (NIS2UmsuCG), verkuendet im Bundesgesetzblatt Teil I am 5. Dezember 2025, in Kraft seit 6. Dezember 2025 (recht.bund.de). Richtlinie (EU) 2022/2555 des Europaeischen Parlaments und des Rates vom 14. Dezember 2022 (NIS-2-Richtlinie), EUR-Lex.

    Dieser Beitrag ist eine Risiko-Einschätzung, keine Rechtsberatung. Erstfassung 04.07.2026, korrigiert am 06.11.2026.

  • Widerrufsbutton-Pflicht ab 19. Juni 2026: Was Online-Shop-Betreiber jetzt wissen müssen
    Symbolbild, KI-generiert

    Widerrufsbutton-Pflicht ab 19. Juni 2026: Was Online-Shop-Betreiber jetzt wissen müssen

    Seit dem 19. Juni 2026 gilt eine neue Pflicht für Online-Shops im B2C-Bereich: Verbraucher müssen ihren Widerruf per Klick auf einen klar beschrifteten Button einleiten können. Die rechtliche Grundlage ist § 356a BGB in der neuen Fassung, der die EU-Omnibus-Richtlinie (Richtlinie 2019/2161) ins deutsche Recht umsetzt. Kein Gesetzestext von gestern — die Frist war bekannt, aber viele Shops haben noch nicht reagiert.

    Was ist neu?

    Bisher konnten Verbraucher ihren Widerruf formlos per E-Mail, Post oder über ein Kontaktformular erklären. Das bleibt möglich — aber Online-Shops müssen jetzt zusätzlich einen digitalen Weg anbieten: einen dauerhaft sichtbaren, klickbaren Widerrufsbutton auf der Shop-Oberfläche.

    Der Gesetzgeber schreibt dabei den genauen Ablauf vor. Der Button muss mit den Worten „Vertrag widerrufen“ beschriftet sein — andere Formulierungen wie „Rückgabe starten“ oder „Kauf rückgängig machen“ genügen der Pflicht nicht. Nach dem ersten Klick folgt eine zweite Stufe: Der Verbraucher bestätigt seinen Widerruf nochmals aktiv. Erst dann gilt er als rechtswirksam erklärt.

    Wen betrifft die Pflicht?

    Betroffen sind alle Unternehmen, die Verträge mit Verbrauchern (B2C) über einen Online-Shop abschließen — unabhängig von Größe, Branche oder Umsatz. Ob WooCommerce-Shop, Shopify-Store oder individuelle Shop-Lösung spielt keine Rolle.

    Ausgenommen sind:

    • Reine B2B-Shops ohne Verbrauchergeschäfte
    • Bestellungen, die ausschließlich per Telefon oder Fax aufgegeben werden
    • Verträge über individuell angefertigte Waren (§ 312g Abs. 2 BGB), zum Beispiel personalisierte Produkte, bei denen kein gesetzliches Widerrufsrecht besteht

    Wer einen gemischten Shop betreibt — also sowohl an Verbraucher als auch an Geschäftskunden verkauft — fällt grundsätzlich unter die Pflicht, sobald auch nur ein B2C-Geschäft möglich ist.

    Was muss der Button technisch leisten?

    Der Button ist kein rein optisches Element. Das Gesetz stellt konkrete Anforderungen:

    • Bezeichnung: ausschließlich „Vertrag widerrufen“
    • Erreichbarkeit: ohne vorherigen Login, direkt über die Shop-Oberfläche zugänglich
    • Gut lesbar und klar erkennbar — keine versteckte Platzierung im Footer hinter drei Klicks
    • Zweitstufiger Prozess: erst Widerruf einleiten, dann bestätigen
    • Verfügbarkeit: dauerhaft während der gesamten Widerrufsfrist (in der Regel 14 Tage)

    Nach Bestätigung muss der Shop den Eingang des Widerrufs auf einem dauerhaften Datenträger bestätigen — also per E-Mail oder vergleichbarem Weg.

    Was droht, wenn der Button fehlt?

    Wer den Widerrufsbutton nicht oder nicht ordnungsgemäß eingebaut hat, riskiert mehreres gleichzeitig.

    Erstens verlängert sich die gesetzliche Widerrufsfrist: Statt 14 Tagen haben Verbraucher dann bis zu 12 Monate und 14 Tage Zeit, vom Kauf zurückzutreten. Das betrifft rückwirkend alle Bestellungen, die ohne ordnungsgemäßen Button abgewickelt wurden.

    Zweitens sieht das Gesetz einen Bußgeldrahmen von bis zu 50.000 Euro vor. Dieser Betrag ist der gesetzliche Maximalrahmen — kein typischer Regelbetrag. Behörden und Gerichte setzen den konkreten Betrag nach Einzelfall an. Dennoch: Für kleine Shops kann das existenzbedrohend werden.

    Drittens ist der Verstoß ein klarer Abmahntatbestand. Mitbewerber und Verbraucherschutzverbände können kostenpflichtige Abmahnungen aussprechen. Gerade in Branchen mit hohem Mitbewerberdruck werden solche Verstöße erfahrungsgemäß schnell aufgegriffen.

    Was prüft der technische Check von Experto Mundi?

    Experto Mundi bietet im Rahmen seines technischen Komplett-Checks für Webseiten und Online-Shops auch eine Analyse des Widerrufsbuttons an. Der Check ist rein technisch und maschinell — kein Ersatz für eine Rechtsberatung, aber ein verlässlicher erster Befund.

    Konkret prüft das System:

    • Ob der Button extern messbar auf der Shop-Oberfläche vorhanden ist
    • Ob typische Shop-Fingerprints (WooCommerce, Shopify, Shopware und andere) erkennbar sind, die auf B2C-Verkäufe hindeuten
    • Eine Konfidenzangabe, wie sicher das System ist, dass es sich um einen B2C-Shop handelt

    Das Ergebnis ist ein technischer Befund — kein Rechtsgutachten. Ob der Button die gesetzlichen Anforderungen im Einzelfall vollständig erfüllt, muss ein Fachanwalt beurteilen. Der Check zeigt aber schnell, ob überhaupt Handlungsbedarf besteht.

    Was sollten Sie jetzt tun?

    Wenn Sie einen Online-Shop mit B2C-Anteil betreiben, sind drei Schritte sinnvoll:

    • Prüfen Sie, ob Ihr Shop-System den Widerrufsbutton bereits mitliefert — viele Systeme haben entsprechende Erweiterungen oder Updates herausgegeben.
    • Lassen Sie den technischen Status Ihres Shops von außen prüfen, um blinde Flecken zu vermeiden.
    • Konsultieren Sie einen Fachanwalt für IT-Recht oder Vertragsrecht, um die rechtliche Konformität Ihrer Widerrufsbelehrung und des Button-Prozesses zu bestätigen.

    Die Pflicht gilt seit dem 19. Juni 2026. Je länger der Button fehlt, desto länger verlängert sich die Widerrufsfrist für laufende und vergangene Bestellungen.

    Jetzt Widerrufsbutton-Check anfordern


    Quellen

    Buergerliches Gesetzbuch (BGB), Paragraf 356a in der seit 19. Juni 2026 geltenden Fassung (gesetze-im-internet.de). Paragraf 312g Absatz 2 BGB zu individuell angefertigten Waren (gesetze-im-internet.de). Richtlinie (EU) 2019/2161 des Europaeischen Parlaments und des Rates vom 27. November 2019 zur besseren Durchsetzung und Modernisierung der Verbraucherschutzvorschriften der Union (Omnibus-Richtlinie), EUR-Lex.

    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: 25.06.2026.

WhatsApp