Datenklau, Tracking-Missbrauch und Datenschutzdelikte

Consent Fraud bezeichnet das Fälschen oder Manipulieren von Einwilligungen, etwa für Werbe-E-Mails, Werbeanrufe oder Cookies. Dazu gehören erfundene Opt-ins in gekauften Adresslisten, durch Bots ausgelöste Bestätigungen und Consent-Banner, die eine Zustimmung speichern, die nie gegeben wurde.

So funktioniert Consent Fraud

Profiteure sind häufig unseriöse Lead-Händler, die Kontakte mit angeblicher Werbeeinwilligung verkaufen, oder Dienstleister, die Zustimmungsquoten künstlich aufblähen. Das Risiko trägt das werbende Unternehmen: Nach der DSGVO muss der Verantwortliche nachweisen können, dass eine Einwilligung wirksam erteilt wurde. Fehlt dieser Nachweis, drohen Abmahnungen, Beschwerden bei Aufsichtsbehörden und Imageschäden.

Beispiel

Ein Energieversorger kauft Leads mit dokumentierter Einwilligung für Telefonwerbung. Nach zahlreichen Beschwerden zeigt sich, dass die Angerufenen nie an dem angegebenen Gewinnspiel teilgenommen haben; Zeitstempel und IP-Adressen in den Nachweisen waren erfunden.

Warnsignale und Schutz

• Einwilligungsnachweise ohne nachvollziehbare Quelle
• Hohe Beschwerde- oder Abmeldequoten bei frischen Kontakten
• Unplausibel hohe Zustimmungsquoten im Consent-Banner

Prüfen Sie Datenlieferanten sorgfältig, nutzen Sie Double-Opt-in und lassen Sie Ihre Einwilligungsprozesse rechtlich prüfen. Mehr dazu im Schutzbereich Blackhat-Angriffe.

Ein CRM Breach ist ein Sicherheitsvorfall, bei dem die Vertraulichkeit, Integrität oder Verfügbarkeit von Informationen in einem Customer-Relationship-Management-System verletzt wird. Ein CRM verwaltet beispielsweise Kundenkontakte, Anfragen, Gesprächsverläufe, Angebote und Vertriebschancen. Unberechtigte Personen können dadurch Informationen erhalten, die weit über eine einfache Adressliste hinausgehen: Welche Geschäftsbeziehung besteht, welcher Bedarf ist bekannt und welche Entscheidung wird vorbereitet?

Ein ungewöhnlicher CRM-Export ist noch kein Datenleck. Vertrieb, Support und befugte Integrationen benötigen häufig legitime Datenzugriffe. Ebenso setzt ein CRM Breach nicht zwingend einen Fehler im Kernsystem des Softwareherstellers voraus. Angreifer können gestohlene Anmeldedaten, missbrauchte Integrationen oder falsch vergebene Rechte verwenden. Entscheidend sind die tatsächliche Berechtigung, die verarbeiteten Daten und die dokumentierten Vorgänge.

Welche Daten und Geschäftsprozesse sind betroffen?

Die Datensätze eines CRM enthalten häufig personenbezogene Angaben von Kunden und Beschäftigten. Neben Namen, E-Mail-Adressen und Telefonnummern können Gesprächsnotizen, Termine, Bestellhistorien und Informationen über Angebote vorhanden sein. In einigen Unternehmen werden Beschwerden oder sensible Geschäftssituationen darin erfasst. Welche Datenarten tatsächlich gespeichert sind, muss für das verwendete System festgestellt werden.

Auch ohne Kundendaten im engeren Sinn kann ein Angriff wirtschaftliche Folgen haben. Ein fremder Zugriff auf nicht öffentliche Preisvereinbarungen, laufende Ausschreibungen oder vertrauliche Produktpläne kann Geschäftsgeheimnisse betreffen. Eine solche Information ist nicht allein aufgrund ihrer Speicherung im CRM automatisch als gesetzlich geschütztes Geschäftsgeheimnis einzuordnen; die Voraussetzungen des GeschGehG sind gesondert zu prüfen.

Bei einem kompromittierten CRM können die Informationen als Ausgangspunkt weiterer Betrugsversuche dienen. Ein falscher Lieferant kann etwa die echte Angebotsnummer kennen oder sich auf ein tatsächlich geführtes Kundengespräch beziehen. Der genaue spätere Missbrauch ist von der ursprünglichen Datenverletzung zu unterscheiden.

Wie kann ein Angreifer auf ein CRM zugreifen?

Gestohlene Zugangsdaten

Über Phishing oder Infostealer können Anmeldeinformationen in fremde Hände gelangen. Ein erfolgreicher Login kann dann die im CRM zugelassenen Funktionen verwenden. Die tatsächliche Reichweite hängt von den Rechten des betroffenen Kontos ab. Ein einfacher Vertriebszugang muss nicht über vollständige Export- oder Administrationsrechte verfügen.

Manipulierte OAuth-Freigaben

Viele CRM-Systeme erlauben die Verbindung mit anderen Anwendungen über OAuth. Dabei kann eine externe App nach Freigabe bestimmte Funktionen und Daten im Rahmen der eingeräumten Berechtigungen verwenden. Ein Angreifer kann versuchen, einen Beschäftigten zur Autorisierung einer falsch dargestellten Anwendung zu bewegen. Die Anwendung benötigt dann nicht zwingend das Passwort des Benutzers, um über einen gültigen Token API-Aufrufe auszuführen.

Microsoft Security Research berichtete am 13. Juli 2026 über entsprechende Angriffe gegen SaaS- und CRM-Umgebungen. Beobachtet wurden unter anderem Anrufe angeblicher Supportmitarbeiter, die Beschäftigte zur Autorisierung einer fremden Connected App veranlassten. Auch kompromittierte Drittanbieterintegrationen wurden als Zugriffsweg beschrieben. Microsoft stellte ausdrücklich klar, dass solche Vorgänge nicht auf eine Sicherheitslücke des Salesforce-Kernsystems zurückgingen.

Kompromittierte Drittanbieterintegration

Ein Unternehmen kann CRM-Daten mit Vertriebs-, Support- oder Marketingwerkzeugen austauschen. Wird eine dieser Integrationen bei ihrem Anbieter kompromittiert, können vorhandene Zugriffsrechte missbraucht werden. Salesforce berichtete beispielsweise über den Vorfall mit der Salesloft-Drift-Integration im Jahr 2025 und über die Sperrung beziehungsweise Erneuerung betroffener Verbindungstokens. Das zeigt eine real dokumentierte Angriffskonstellation; es bedeutet nicht, dass jede CRM-Integration unsicher wäre.

Zu weitreichende Mitarbeiterrechte

Ein CRM-Konto kann Daten mehrerer Geschäftsbereiche sehen oder exportieren, obwohl seine berufliche Aufgabe dies nicht verlangt. Wird dieses Konto kompromittiert, kann der unberechtigte Zugriff entsprechend weit reichen. Ein falsches Rechtekonzept ist ein organisatorisches Problem, aber nicht in jedem Fall das Ergebnis eines Angriffs.

Fehlerhafte Schnittstellenberechtigungen

Eine API kann unzureichend prüfen, ob ein Benutzer bestimmte Kundenobjekte lesen oder verändern darf. Das kann dazu führen, dass Daten aus einer anderen Organisation oder einer nicht freigegebenen Abteilung abrufbar werden. Die technische Ursache muss anhand der konkreten Anwendung untersucht werden; ein Fehlverhalten der API ist nicht automatisch eine Schwachstelle jedes verwendeten CRM-Produkts.

Unberechtigte interne Exporte

Auch eine Person mit einem legitimen Mitarbeiterkonto kann Informationen entgegen ihren tatsächlichen Befugnissen herunterladen und weitergeben. Eine Berechtigung für bestimmte Vertriebstätigkeiten ist nicht automatisch eine Erlaubnis zur privaten Übernahme des Kundenstamms. Die einzelnen Datenverwendungen und die für den Beschäftigten geltenden Rechte müssen getrennt geprüft werden.

CRM Breach und Data Breach unterscheiden

Data Breach ist der weiter gefasste Begriff für Sicherheitsverletzungen. Im Datenschutzrecht kommt es speziell auf die Verletzung des Schutzes personenbezogener Daten nach Artikel 4 Nr. 12 DSGVO an. Ein CRM Breach beschreibt den betroffenen Geschäftsprozess und das verwendete System.

Bei Data Theft steht die unberechtigte Entwendung von Daten im Vordergrund. Ein CRM Breach kann ebenso eine unerlaubte Veränderung wichtiger Kundeneinträge oder den Verlust ihrer Verfügbarkeit umfassen. Nicht jeder CRM-Vorfall ist daher gleichbedeutend mit einem vollständigen Export sämtlicher Kontakte.

Ein Database Leak kann entstehen, wenn beispielsweise ein CRM-Export über eine falsch konfigurierte Dateiablage öffentlich abrufbar wird. Hier muss kein Dritter zuvor ein Benutzerkonto übernommen haben.

Warum ist ein OAuth-Vorfall nicht zwingend im gewöhnlichen Loginbericht sichtbar?

Eine bereits berechtigte Connected App kann API-Aufrufe über zuvor gewährte Berechtigungen ausführen. Im normalen Mitarbeiterloginbericht erscheint deshalb nicht unbedingt jedes spätere Datenabrufereignis als neue Passwortanmeldung. Microsoft beschreibt bei real untersuchten Vorfällen API-intensive Datenabfragen und anomale Aktivitäten genehmigter Anwendungen als mögliche Prüfsignale.

Für die Untersuchung sind daher die aktiven Integrationen, ihre technischen Berechtigungen und die verfügbaren Auditprotokolle wichtig. Ein Unternehmen kann nicht allein aus der Abwesenheit ungewöhnlicher Passwortlogins schließen, dass keine CRM-Daten über eine fremde Anwendung erreicht wurden.

Gleichwohl ist ein hoher API-Verbrauch nicht automatisch ein Angriff. Regelmäßige Synchronisationen mit erlaubten Kundendienst- oder Reportingwerkzeugen können große Datenmengen übertragen. Die konkreten Anwendungskennungen, der genehmigte Zweck und die tatsächlichen Zugriffe müssen miteinander verglichen werden.

Ein dokumentierter Fall mit einer Drittanbieterintegration

Salesforce veröffentlichte nach dem Vorfall um die Salesloft-Drift-App Informationen zu unberechtigten Zugriffen über Verbindungstokens. In seinen Empfehlungen nannte Salesforce insbesondere die Prüfung verbundener Anwendungen, die Kontrolle von Zugriffsprotokollen und gegebenenfalls die Rotation beziehungsweise den Widerruf von Tokens. Der Vorfall betraf eine externe Verbindung zur CRM-Umgebung, nicht eine nachgewiesene Schwachstelle der Salesforce-Kernplattform.

Diese konkrete Herstellerinformation ist eine fachliche Referenz für das Angriffsmuster. Ob ein anderes Unternehmen davon betroffen war, folgt nicht allein daraus, dass es dieselbe CRM-Plattform verwendet. Für jeden neuen Vorfall sind die tatsächlich aktivierten Integrationen und deren Berechtigungen zu überprüfen.

Ein fiktiver Vorfall im Maschinenbauvertrieb

Ein Maschinenbauunternehmen erfährt von Kunden, dass sie E-Mails mit angeblich geänderten Bankverbindungen erhalten. Die Nachrichten nennen echte Angebotsnummern und Ansprechpartner. Eine erste Prüfung des eigenen Mailservers zeigt keine nachweisbar kompromittierte Versanddomain.

Die IT untersucht daraufhin das CRM und die dort aktivierten Drittanwendungen. Eine bislang unbekannte Integration hat über ein Mitarbeiterkonto umfangreiche Kunden- und Angebotsdaten abgerufen. Ob die tatsächlichen Zahlungsbetrugsversuche aus diesem Zugriff entstanden sind, muss anhand des zeitlichen Verlaufs und weiterer Belege untersucht werden.

Die fremde Integration wird nach der erforderlichen Beweissicherung kontrolliert widerrufen. Das Unternehmen prüft die betroffenen Datenarten und informiert seine zuständigen Datenschutzfachleute. Gegenüber Kunden werden zunächst nur die bestätigten falschen Zahlungsaufforderungen und offiziellen Bankverbindungen richtiggestellt.

Welche technischen Hinweise helfen bei der Erkennung?

Ein CRM bietet je nach Produkt unterschiedliche Protokolle für Benutzeranmeldungen, Exporte, API-Abfragen und Connected Apps. Ein einzelner auffälliger Wert genügt selten für eine sichere Diagnose.

• Neue Connected Apps: Eine unbekannte Anwendung besitzt plötzlich Zugriffsrechte auf große CRM-Datenbestände.
• Ungewöhnliche Exporte: Umfangreiche Kontakt- oder Berichtsausgaben erscheinen ohne dokumentierten Geschäftsauftrag.
• API-Verhalten: Integrationen rufen neue Datenkategorien oder auffällig viele Datensätze ab.
• Berechtigungen: Neue Rollen, Administrationsrechte oder Servicekonten wurden nicht freigegeben.
• Änderungen an Kundenstammdaten: Zahlungs- oder Kontaktdaten werden ohne bestätigte Veranlassung verändert.
• Externe Betrugsnachrichten: Kunden erhalten Nachrichten mit CRM-Details, deren Herkunft ungeklärt ist.
• Reguläre Erklärungen: Eine genehmigte CRM-Migration oder eine neue Reportingintegration kann ähnliche Abfragen verursachen.

Wie wird ein CRM Breach untersucht und eingegrenzt?

Der erste Schritt ist die Feststellung, welche Konten und Integrationen tatsächlich Zugriff besitzen. Besteht ein begründeter Fremdzugriffsverdacht, sollten die relevanten Protokolle und aktuellen Berechtigungen gesichert werden. Danach können unberechtigte Tokens, Sessions und Benutzerrechte kontrolliert widerrufen werden. Die konkrete Reihenfolge hängt vom Risiko laufender Zugriffe und von den Möglichkeiten der Beweissicherung ab.

Auch die Datenarten sind zu bestimmen. Ein vollständiger Zugriff auf eine Kundentabelle kann andere Folgen besitzen als eine Änderung einzelner Termine. Es ist zu klären, ob Daten nur gelesen werden konnten, tatsächlich exportiert oder verändert wurden und welche Angaben betroffene Personen identifizieren.

Eine plötzliche Löschung der gesamten CRM-Integration kann produktive Systeme beeinträchtigen und wichtige Spuren verändern. Deshalb sollten die beteiligten Fachabteilungen und der Sicherheitsverantwortliche die notwendigen Sofortmaßnahmen abstimmen.

• Betroffene Benutzer, Connected Apps und technischen Servicekonten inventarisieren.
• Relevante Anmelde-, API- und Exportprotokolle sichern.
• Unberechtigte Zugriffsrechte und Tokens nach Bedarf kontrolliert widerrufen.
• Den Umfang der tatsächlich betroffenen Datensätze und Geschäftsvorgänge bestimmen.
• Weitere angeschlossene Systeme bei konkretem Verdacht gesondert prüfen.
• Gesetzliche Prüf- und Meldepflichten gemeinsam mit Datenschutz- und Rechtsfachleuten beurteilen.

Welche Pflichten entstehen nach der DSGVO?

Enthält der CRM-Vorfall eine Verletzung des Schutzes personenbezogener Daten, gelten die Vorgaben nach Artikel 33 und gegebenenfalls Artikel 34 DSGVO. Eine Meldung an die zuständige Aufsichtsbehörde ist nach Artikel 33 grundsätzlich ohne unangemessene Verzögerung und möglichst binnen 72 Stunden ab Bekanntwerden erforderlich, sofern die gesetzliche Ausnahme wegen voraussichtlich fehlenden Risikos für die Rechte und Freiheiten natürlicher Personen nicht greift.

Für die Information betroffener Personen nach Artikel 34 gilt eine andere Schwelle: Der Vorfall muss voraussichtlich ein hohes Risiko mit sich bringen, sofern keine gesetzliche Ausnahme eingreift. Nicht jeder verdächtige CRM-Login löst beide Pflichten automatisch aus. Ein bestätigter Datenvorfall ist nach Artikel 33 Abs. 5 zu dokumentieren, auch wenn keine behördliche Meldung erforderlich ist.

Arbeitet ein externer CRM-Anbieter als Auftragsverarbeiter, muss er den Verantwortlichen nach Artikel 33 Abs. 2 ohne unangemessene Verzögerung informieren, wenn ihm eine solche Datenverletzung bekannt wird. Die Rollen der Beteiligten richten sich nach der tatsächlichen Verarbeitung und den Verträgen.

Welche Schutzmaßnahmen senken das CRM-Risiko?

Die Kontosicherheit allein reicht nicht, wenn externe Integrationen mit weitreichenden Rechten verbunden sind. Unternehmen sollten deshalb sowohl Benutzerberechtigungen als auch verbundene Apps und ihre erlaubten Datenobjekte dokumentieren. Nicht mehr benötigte Integrationen können kontrolliert entfernt werden.

• Mehrfaktor-Authentisierung und angemessene Rollen für CRM-Benutzer einsetzen.
• Connected Apps und OAuth-Berechtigungen regelmäßig auf ihren geschäftlichen Zweck prüfen.
• Servicekonten mit möglichst wenigen tatsächlich erforderlichen Rechten betreiben.
• Ungewöhnliche Datenexporte und API-Zugriffe mit verfügbaren Auditfunktionen kontrollieren.
• Bei Dienstleisterwechseln alte Integrationen und Tokens kontrolliert widerrufen.
• CRM-Exporte und Backups vor unberechtigter externer Freigabe schützen.
• Reale Kundenkommunikation bei bestätigten Betrugsversuchen über verifizierte Kanäle absichern.

Ein technischer Kontozugriffsschutz verhindert nicht jede absichtliche missbräuchliche Handlung einer bereits berechtigten Person. Berechtigungsprüfung, Datensparsamkeit und nachvollziehbare Geschäftsfreigaben müssen zusammenpassen.

Häufige Fragen zu CRM Breach

Muss der CRM-Anbieter selbst gehackt worden sein?

Nein. Gestohlene Benutzerkonten und kompromittierte Drittanbieterintegrationen können eine CRM-Umgebung betreffen, ohne dass der Softwarekern eine Sicherheitslücke aufweist.

Beweist ein umfangreicher Export einen Datendiebstahl?

Nein. Auch genehmigte Datenmigrationen können große Exporte auslösen. Berechtigung, Zweck und tatsächlicher Datenfluss sind zu prüfen.

Reicht ein neues CRM-Passwort aus?

Nicht zwingend. Bei missbrauchten OAuth-Tokens oder weiterhin autorisierten Connected Apps können zusätzliche Maßnahmen zum Widerruf der Berechtigungen notwendig sein.

Ist jeder CRM-Vorfall binnen 72 Stunden meldepflichtig?

Nein. Artikel 33 DSGVO besitzt bestimmte Voraussetzungen und eine gesetzliche Risikoausnahme. Eine konkrete Datenschutzverletzung muss geprüft und dokumentiert werden.

Wo können betroffene Unternehmen Hilfe erhalten?

Bei verdächtigen CRM-Zugriffen sollten Unternehmen die IT-Sicherheit, den CRM-Administrator und die zuständigen Datenschutzfachleute einbeziehen. BRANDPROTECTIONNOW unterstützt bei der Analyse digitaler Folgeangriffe, etwa wenn gestohlene Vertriebsinformationen für gefälschte Lieferantenrechnungen, Phishing oder Markenimitation verwendet werden. Die Dokumentation und passende öffentliche Schutzmaßnahmen werden mit spezialisierten Security-Partnern abgestimmt. Der Zugang zu einer kompromittierten CRM-Umgebung muss durch die zuständigen technischen Fachleute gesichert werden. Für damit verbundene Phishing- und Website-Angriffe bietet BRANDPROTECTIONNOW Schutz vor Blackhat- und Website-Angriffen; für falsche Firmenidentitäten ergänzt digitaler Markenschutz das Vorgehen.

Fachquellen

• Microsoft Security Research (Juli 2026): OAuth-Angriffe auf SaaS- und CRM-Integrationen.
• Salesforce – Drift-Integration und unberechtigter CRM-Zugriff: Herstellerhinweise und Tokenmaßnahmen.
• MITRE ATT&CK – CRM Software Data (T1213.004): Datensammlung aus CRM-Systemen.
• DSGVO – Artikel 4 Nr. 12, 33 und 34: Datenverletzungen und Meldepflichten.
• § 2 GeschGehG: Voraussetzungen für den Schutz von Geschäftsgeheimnissen.

Dark Pattern Abuse bezeichnet den Einsatz manipulativer Gestaltung, die Nutzer zu Entscheidungen drängt, die sie so nicht treffen wollten. Typisch sind versteckte Ablehnen-Schaltflächen, vorangekreuzte Zusatzoptionen, künstliche Verknappung oder Kündigungswege, die bewusst kompliziert gestaltet sind.

So funktioniert Dark Pattern Abuse

Dark Patterns nutzen Gewohnheiten und Zeitdruck aus: Die gewünschte Option ist farbig hervorgehoben, die Alternative kaum sichtbar. Kurzfristig steigen Einwilligungs- und Konversionsraten. Langfristig schadet das: Einwilligungen können unwirksam sein, Verbraucherschützer und Aufsichtsbehörden achten zunehmend auf solche Muster, und enttäuschte Kunden reagieren mit Kündigungen, Rückbuchungen und schlechten Bewertungen. Auch Fake-Shops und Betrüger setzen gezielt auf diese Tricks.

Beispiel

Ein Abo-Dienst versteckt den Kündigungsbutton in einem verschachtelten Menü und blendet beim Kündigen mehrere Rückfragen mit irreführenden Schaltflächen ein. Die Folge sind Beschwerden, negative Bewertungen und Rückbuchungen frustrierter Kunden.

Warnsignale und Schutz

• Ablehnen ist schwerer erreichbar als Zustimmen
• Vorausgewählte Kästchen für Zusatzleistungen oder Werbung
• Countdowns oder Bestandsanzeigen ohne realen Hintergrund

Ein ehrliches Design-Review Ihrer Banner, Checkouts und Kündigungswege sowie eine rechtliche Prüfung schaffen Vertrauen statt Risiko. Mehr dazu im Schutzbereich Blackhat-Angriffe.

Data Breach bezeichnet eine Verletzung der Datensicherheit. Der Begriff kann allgemein für unerlaubte Zugriffe, Datenverluste oder andere Sicherheitsvorfälle verwendet werden. Im Datenschutzrecht besitzt er eine genauere Bedeutung: Nach Artikel 4 Nr. 12 DSGVO liegt eine Verletzung des Schutzes personenbezogener Daten vor, wenn eine Sicherheitsverletzung bewirkt, dass personenbezogene Daten unbeabsichtigt oder unrechtmäßig vernichtet, verloren, geändert, unbefugt offengelegt oder unbefugt eingesehen werden.

Damit umfasst ein Data Breach mehr als einen Hackerangriff mit gestohlener Kundendatenbank. Auch eine versehentliche Offenlegung, gelöschte personenbezogene Daten ohne geeignete Wiederherstellung oder unberechtigte Änderungen können darunter fallen. Nicht jeder technische Zwischenfall ist jedoch eine Verletzung personenbezogener Daten. Die betroffenen Informationen und tatsächlichen Folgen müssen festgestellt werden.

Welche Arten von Datenverletzungen gibt es?

Verletzung der Vertraulichkeit

Personenbezogene Informationen werden einer nicht berechtigten Person zugänglich. Das kann durch ein kompromittiertes Benutzerkonto, falsch adressierte E-Mails, einen öffentlich erreichbaren Datenspeicher oder andere Ursachen geschehen. Ein tatsächlicher Download durch Dritte ist nicht in jedem Fall Voraussetzung für einen unbefugten Zugang.

Verletzung der Integrität

Daten werden ohne Berechtigung oder unbeabsichtigt verändert. Ein Beispiel ist eine falsche Zuordnung von Kundendatensätzen durch einen technischen Fehler. Die Änderung kann Folgen für Personen haben, obwohl keine Informationen nach außen abgeflossen sind.

Verletzung der Verfügbarkeit

Personenbezogene Daten werden zerstört oder stehen nicht mehr in der erforderlichen Form zur Verfügung. Ransomware oder ein Ausfall ohne wiederherstellbare Sicherung können solche Vorfälle verursachen. Die genaue DSGVO-Bewertung hängt davon ab, ob tatsächlich eine Sicherheitsverletzung und die im Gesetz genannten Folgen vorliegen.

Die europäische Datenschutzsystematik betrachtet damit Vertraulichkeit, Integrität und Verfügbarkeit. Die Begriffe sollten bei einer Vorfalluntersuchung nicht auf das bloße Kopieren von Daten reduziert werden.

Wie kann ein Data Breach entstehen?

Ein Sicherheitsvorfall kann auf gestohlene Zugangsdaten, verwundbare Anwendungen, falsch konfigurierte Cloudspeicher oder fehlerhaft ausgeführte administrative Tätigkeiten zurückgehen. Auch verlorene Geräte und fehlgeleitete Dokumente können betroffen sein. Ein externer Angreifer ist keine notwendige Voraussetzung.

Bei einem Phishing-Vorfall kann eine Mitarbeiterin ihre Zugangsdaten auf einer fremden Seite eingeben. Ob daraus ein Data Breach entsteht, hängt von den nachfolgenden Zugriffen und betroffenen personenbezogenen Daten ab. Der Empfang der Phishing-Nachricht allein erfüllt die Definition einer Datenverletzung nicht.

Bei einer Ransomware-Attacke kann der Zugang zu Dateien unterbrochen werden. Eine mögliche Datenkopie ist gesondert zu ermitteln. Die Lösegeldforderung eines Angreifers belegt für sich nicht, dass jede behauptete Datei tatsächlich entwendet wurde.

Data Breach, Data Theft und Database Leak unterscheiden

Data Theft bezeichnet die gezielte unberechtigte Entwendung oder das Kopieren von Informationen. Dabei können auch reine Geschäftsdaten ohne Personenbezug betroffen sein. Ein Data Breach im Sinne der DSGVO benötigt dagegen eine tatsächliche Verletzung des Schutzes personenbezogener Daten, kann aber auch unbeabsichtigt entstehen.

Database Leak beschreibt eine Situation, in der Datenbankinhalte unberechtigt offengelegt oder öffentlich abrufbar werden. Ein solcher Leak kann Folge eines Angriffs oder einer Fehlkonfiguration sein. Die rechtlichen Anforderungen richten sich nach dem konkreten Dateninhalt und Vorfall.

Die Begriffe sind für die Aufklärung keine austauschbaren Synonyme. Ein Verlust verschlüsselter Daten, ein kompromittiertes Kundenkonto und ein öffentlich abrufbarer Datenbankexport können unterschiedliche Maßnahmen erfordern.

Ein fiktiver Fall aus einem Onlineshop

Ein Händler entdeckt, dass ein Export mit Kundennamen und Lieferadressen über eine falsch konfigurierte Dateiablage erreichbar war. Die Datei wurde zunächst für eine interne Auswertung angelegt. Die Sicherheitsabteilung sperrt den Zugriff und sichert die vorhandenen Protokolle.

Jetzt muss geklärt werden, welche Daten betroffen waren, wie lange der unberechtigte Zugang bestand und welche Personen ein Risiko tragen könnten. Der bloße Fund einer öffentlich erreichbaren Datei beweist nicht, dass ihre Inhalte bereits verkauft oder weiterverbreitet wurden. Der fehlende Nachweis eines Downloads entbindet das Unternehmen aber nicht von einer sachgerechten Risikobewertung.

Für eine mögliche Meldung sind die einschlägigen DSGVO-Kriterien maßgebend. Der Verantwortliche kann nicht warten, bis jede technische Einzelheit vollständig geklärt ist, wenn die Voraussetzungen einer gesetzlichen Frist bereits vorliegen.

Welche Sofortmaßnahmen sind sinnvoll?

Nach dem Bekanntwerden eines möglichen Vorfalls sollten Ursache und weitere unberechtigte Zugriffe eingegrenzt werden. Daneben müssen vorhandene Beweise gesichert und die tatsächlich betroffenen Informationen erfasst werden. Eine unkoordinierte Löschung kann die spätere Rekonstruktion erschweren.

• Die Sicherheitsverletzung und ihre technische Ursache so weit wie möglich eingrenzen.
• Betroffene Systeme, Datenarten und verantwortliche Stellen identifizieren.
• Vorhandene Logdaten und Konfigurationsstände nachvollziehbar sichern.
• Unberechtigte Zugänge sperren und betroffene Rechte kontrollieren.
• Risikofolgen für betroffene Personen dokumentieren.
• Bestehende Melde- und Informationspflichten fristgerecht beurteilen.

Wann muss nach Artikel 33 DSGVO gemeldet werden?

Artikel 33 DSGVO verlangt vom Verantwortlichen unter den gesetzlichen Voraussetzungen eine Meldung an die zuständige Aufsichtsbehörde ohne unangemessene Verzögerung und möglichst binnen 72 Stunden ab Bekanntwerden, sofern die Verletzung des Schutzes personenbezogener Daten voraussichtlich nicht ohne Risiko für die Rechte und Freiheiten natürlicher Personen bleibt. Ist eine solche Verletzung voraussichtlich nicht mit einem Risiko verbunden, greift die in Artikel 33 genannte Ausnahme von der behördlichen Meldepflicht.

Ein Auftragsverarbeiter muss den Verantwortlichen nach Artikel 33 Abs. 2 ohne unangemessene Verzögerung informieren, sobald ihm eine Datenverletzung bekannt wird. Die DSGVO schreibt also nicht für jede beteiligte Stelle denselben Meldeweg vor.

Eine Meldepflicht besteht nicht schon wegen jeder fehlgeschlagenen Anmeldung oder jeder verdächtigen E-Mail. Der konkrete Datenvorfall und die gesetzlichen Voraussetzungen sind zu prüfen. Artikel 33 Abs. 5 verlangt auch die Dokumentation von Verletzungen des Schutzes personenbezogener Daten.

Wann müssen betroffene Personen informiert werden?

Artikel 34 DSGVO betrifft die Benachrichtigung der betroffenen Personen. Sie ist unter den gesetzlichen Voraussetzungen erforderlich, wenn die Verletzung voraussichtlich ein hohes Risiko für deren Rechte und Freiheiten zur Folge hat. Der Schwellenwert ist damit nicht identisch mit der behördlichen Meldepflicht aus Artikel 33.

Artikel 34 enthält bestimmte Ausnahmen, etwa wenn geeignete Schutzmaßnahmen die betroffenen Daten für unberechtigte Personen unverständlich gemacht haben. Ob eine Ausnahme tatsächlich greift, muss für den Einzelfall begründet werden. Eine pauschale Aussage, jede Datenpanne müsse sofort sämtlichen Kunden öffentlich mitgeteilt werden, wäre falsch.

Welche zusätzlichen Pflichten können nach BSIG gelten?

Seit dem 6. Dezember 2025 gelten in Deutschland die Vorschriften des NIS-2-Umsetzungsgesetzes. Das BSI verweist für die betroffenen Einrichtungen auf das vorgesehene Registrierungs- und Meldeverfahren über das BSI-Portal. Die konkreten Pflichten hängen von der Einordnung des Unternehmens und dem jeweiligen Sicherheitsvorfall ab.

Diese Regeln bestehen neben der DSGVO. Nicht jeder Betrieb ist meldepflichtig nach dem BSIG, und nicht jeder Cyberangriff enthält personenbezogene Daten. Eine gesetzlich erforderliche Meldung an eine Stelle ersetzt nicht automatisch eine andere.

Wie lässt sich die Auswirkung eines Vorfalls bewerten?

Eine Risikoanalyse benötigt den Umfang der Daten, die betroffenen Personen und die tatsächlichen Folgen. Geschäftliche Kontaktdaten können ein anderes Gefährdungspotenzial aufweisen als Gesundheitsinformationen oder Zugangsdaten. Ebenso macht es einen Unterschied, ob die Daten verschlüsselt und nachweislich unzugänglich für Unberechtigte waren.

Die Schätzung einer Schadenssumme muss von einer Risikobewertung für Personen getrennt werden. Ein Unternehmen kann erhebliche eigene Kosten haben, auch wenn keine personenbezogene Datenverletzung festgestellt wird.

Häufige Fragen zu Data Breach

Ist ein Data Breach immer ein Hackerangriff?

Nein. Auch versehentliche Offenlegung, Verlust oder Änderung personenbezogener Daten können die gesetzliche Definition erfüllen.

Muss jeder Vorfall binnen 72 Stunden gemeldet werden?

Nein. Artikel 33 DSGVO enthält bestimmte Voraussetzungen und eine Risikoausnahme. Wenn die Meldepflicht besteht, gelten die dort genannten Fristen.

Beweist eine Lösegeldforderung einen Abfluss aller Kundendaten?

Nein. Die tatsächliche Kopie oder Offenlegung muss gesondert untersucht werden.

Wo können betroffene Unternehmen Hilfe erhalten?

Bei einer vermuteten Datenverletzung sollten Unternehmen zunächst ihre IT-Sicherheit und den Datenschutzverantwortlichen einbeziehen. BRANDPROTECTIONNOW begleitet Unternehmen bei der Dokumentation digitaler Folgeangriffe, der Untersuchung nachgeahmter Unternehmensauftritte und der Abstimmung technischer Maßnahmen mit spezialisierten Security-Partnern. Für die öffentliche Identität und mögliche Reputationsfolgen informiert BRANDPROTECTIONNOW zum Reputationsschutz. Die Prüfung gesetzlicher Meldungen gehört zu den zuständigen Datenschutz- und Rechtsfachleuten.

Fachquellen

• DSGVO – Artikel 4 Nr. 12, 33 und 34: Definition, behördliche Meldung und Betroffeneninformation.
• BSI – Informationen zu NIS-2 und Meldeverfahren: nationale Pflichten seit Dezember 2025.
• MITRE ATT&CK – Transfer Data to Cloud Account: Beispiel für mögliche unberechtigte Datenübertragung.

Data Poisoning bezeichnet das gezielte Einschleusen falscher oder manipulierter Daten in Analytics-, CRM- oder KI-Systeme. Ziel ist, Auswertungen zu verfälschen, Entscheidungen in die Irre zu führen oder das Verhalten lernender Systeme zu beeinflussen. Anders als beim Datendiebstahl werden Daten nicht entwendet, sondern verunreinigt.

So funktioniert Data Poisoning

Bots erzeugen gefälschte Besuche und Ereignisse in der Webanalyse, Formulare füllen das CRM mit erfundenen Kontakten, manipulierte Inhalte gelangen in Trainingsdaten von KI-Modellen. Profiteure sind Saboteure, Betrüger im Werbeumfeld oder Wettbewerber. Für Sie entstehen falsche Kennzahlen, fehlgeleitete Budgets, verfälschte Lead-Scores und KI-Ergebnisse, denen Sie nicht mehr trauen können.

Beispiel

Ein Onlinehändler trainiert ein Empfehlungssystem mit Kundenbewertungen. Nachdem massenhaft gefälschte Bewertungen eingeflossen sind, empfiehlt das System bevorzugt minderwertige Produkte eines bestimmten Anbieters.

Warnsignale und Schutz

• Kennzahlen, die sich ohne erkennbaren Grund sprunghaft ändern
• Viele ähnliche Datensätze aus derselben Quelle
• KI- oder Scoring-Ergebnisse, die nicht zur Realität passen

Die Validierung eingehender Daten, Bot-Filter in Analytics und Formularen sowie nachvollziehbare Datenquellen für KI-Training schützen Ihre Entscheidungsgrundlagen. Mehr dazu im Schutzbereich Blackhat-Angriffe.

Data Scraping bezeichnet das automatisierte Auslesen von Daten aus Websites, Shops oder Plattformen. Gesammelt werden etwa Texte, Produktdaten, Preise, Bewertungen oder Kontaktdaten. Scraping ist nicht per se illegal, wird aber missbräuchlich, wenn Inhalte kopiert, personenbezogene Daten gesammelt oder Systeme überlastet werden.

So funktioniert Data Scraping

Programme, sogenannte Scraper Bots, rufen Seiten massenhaft auf und extrahieren strukturierte Informationen. Profiteure sind Wettbewerber, Datenhändler oder Betreiber von Kopien Ihrer Website. Für Sie entstehen Serverlast, kopierte Inhalte, die in Suchmaschinen mit Ihren Originalen konkurrieren, und im Fall personenbezogener Daten Folgerisiken wie Spam oder Phishing gegen Ihre Nutzer.

Beispiel

Ein Ratgeberportal entdeckt, dass seine Fachartikel wenige Stunden nach Veröffentlichung auf einer fremden Seite erscheinen. Die Kopien sind mit Werbung überladen und ranken teilweise vor dem Original.

Warnsignale und Schutz

• Viele Seitenaufrufe in kurzer Zeit aus denselben Netzen
• Systematisches Durchlaufen von Kategorien oder Produktnummern
• Ihre Inhalte tauchen kurz nach Veröffentlichung anderswo auf

Bot-Management, sinnvolle Abfragebegrenzungen und ein Monitoring auf kopierte Inhalte reduzieren den Datenabfluss. Mehr dazu im Schutzbereich Bot- & Server-Angriffe.

Data Theft bezeichnet das unberechtigte Entwenden oder Kopieren von Informationen. Angreifer können Kundendaten, interne Dokumente, Zugangsinformationen, Quellcode oder vertrauliche Geschäftsunterlagen an sich bringen. Anders als bei einem bloßen Verlust von Dateien bleiben die Originaldaten beim Datendiebstahl häufig im Unternehmen vorhanden. Der Zugriff durch Unberechtigte kann deshalb über längere Zeit unbemerkt bleiben.

Der Begriff ist eine technische und wirtschaftliche Beschreibung, kein eigenständiger Straftatbestand des deutschen Rechts. Nicht jede Dateiübertragung ist ein Datendiebstahl: Beschäftigte, IT-Dienstleister und Geschäftspartner können Daten mit entsprechender Berechtigung verwenden. Für die Bewertung zählen die tatsächlichen Zugriffsrechte, die Herkunft der Daten und der Zweck ihrer Weitergabe.

Wie können Unternehmensdaten entwendet werden?

Ein externer Angreifer kann durch gestohlene Zugangsdaten, verwundbare Systeme oder andere unberechtigte Zugriffe Informationen erreichen. Danach können Dateien kopiert, über Schnittstellen exportiert oder über bestehende Cloudfreigaben an einen fremden Empfänger übermittelt werden. Die technische Methode hängt von der eingesetzten Infrastruktur ab.

MITRE ATT&CK führt unter T1537 – Transfer Data to Cloud Account die Übertragung von Informationen an ein anderes Cloudkonto auf demselben Dienst auf. Der Datentransfer kann dabei auch über normale Freigabe- oder Synchronisierungsfunktionen erfolgen. Diese Funktionen haben legitime geschäftliche Zwecke; problematisch ist ihre unberechtigte Verwendung.

Auch Insider können Daten ohne Berechtigung weitergeben. Dabei darf nicht jede Tätigkeit eines ausscheidenden Mitarbeiters als Datendiebstahl bewertet werden. Die tatsächlich vorhandenen Berechtigungen und die Art der übernommenen Informationen müssen geprüft werden.

Welche Informationen können betroffen sein?

Personenbezogene Kundendaten

Kundenlisten, Kontaktdaten oder andere personenbezogene Informationen können für Identitätsmissbrauch oder weitere Täuschungen eingesetzt werden. Besteht eine tatsächliche Verletzung ihres Schutzes, können die Anforderungen der DSGVO einschlägig sein.

Geschäftsgeheimnisse

Produktentwicklungen, vertrauliche Kalkulationen und nicht öffentliche Geschäftskonzepte können unter bestimmten Voraussetzungen als Geschäftsgeheimnisse geschützt sein. Das GeschGehG verlangt dafür unter anderem angemessene Geheimhaltungsmaßnahmen. Ein Dokument ist nicht allein wegen der internen Überschrift „Vertraulich“ automatisch ein geschütztes Geschäftsgeheimnis.

Quellcode und technische Zugänge

Der Diebstahl von Quellcode, Konfigurationsdateien oder technischen Schlüsseln kann weitere Zugriffe erleichtern. Ob die Information nach der Entwendung tatsächlich für einen Angriff verwendet wurde, muss gesondert festgestellt werden. Die Kopie einer Datei beweist keine spätere Ausführung von Schadsoftware.

Preislisten und Vertriebsunterlagen

Nicht öffentliche Vertragskonditionen, Angebotskalkulationen und Kundenzuordnungen können wirtschaftlich sensibel sein. Die konkrete rechtliche Bewertung hängt davon ab, ob die Daten unter eine geschützte Kategorie fallen und wie sie erlangt oder verwendet wurden.

Dokumente mit gemischten Datenarten

Eine Datei kann Geschäftsgeheimnisse neben personenbezogenen Angaben enthalten. Dann sind unterschiedliche Rechte und Pflichten zu betrachten. Ein Vorfall kann daher eine Prüfung nach dem GeschGehG und nach der DSGVO erfordern.

Data Theft, Data Breach und Database Leak unterscheiden

Data Breach bezeichnet im Datenschutzrecht eine Verletzung der Sicherheit personenbezogener Daten. Diese kann auch durch unbeabsichtigten Verlust, Änderung oder Löschung entstehen. Data Theft beschreibt dagegen gezielt die unberechtigte Entwendung und kann auch Daten ohne Personenbezug betreffen.

Database Leak meint die unberechtigte öffentliche Zugänglichkeit oder Verbreitung von Datenbankinhalten. Ein Leak kann nach einem Diebstahl entstehen, aber auch durch eine Fehlkonfiguration. Datendiebstahl muss nicht zwangsläufig zu einer öffentlichen Veröffentlichung führen.

Ein Ransomware-Vorfall kann mit Datendiebstahl verbunden sein, etwa wenn Angreifer eine Kopie vertraulicher Dateien behaupten. Eine Lösegeldforderung allein beweist jedoch nicht, dass die gesamten angegebenen Daten tatsächlich kopiert wurden.

Ein fiktiver Vorfall bei einem Softwareanbieter

Ein Unternehmen entdeckt, dass ein bisher wenig verwendetes Cloudkonto mehrere vertrauliche Entwicklungsdokumente mit einer fremden Organisation geteilt hat. Die betroffenen Dateien sind weiterhin im Originalspeicher vorhanden. Das Sicherheitsteam prüft zunächst, ob eine genehmigte Zusammenarbeit oder ein früherer Projektzugang besteht.

Die Auditprotokolle zeigen eine nicht autorisierte Freigabe. Danach wird untersucht, welcher Account die Änderung veranlasst hat und ob die Dokumente tatsächlich abgerufen wurden. Der unberechtigte Zugang ist eine Feststellung; die Identität des verantwortlichen Menschen und die spätere Verwendung der Informationen bleiben weitere Fragen.

Das Unternehmen begrenzt den Zugang nach der Beweissicherung und überprüft, ob weitere Freigaben betroffen sind. Eine pauschale öffentliche Behauptung über einen vollständigen Quellcodediebstahl wäre ohne zusätzliche Nachweise unangebracht.

Welche technischen Hinweise können auf Data Theft deuten?

MITRE nennt ungewöhnliche Cloudfreigaben, Exporte und die Übertragung von Daten in andere Konten als mögliche Spuren. Auch ein großer ausgehender Datenstrom kann auffällig sein. Er ist jedoch nicht automatisch ein Diebstahl: Sicherungen, Partnerübertragungen und reguläre Datenmigrationen können ähnlich aussehen.

• Neue Freigaben: Vertrauliche Ordner werden ohne Genehmigung für externe Konten geöffnet.
• Ungewöhnliche Exporte: Große oder besonders sensible Datensätze werden über unbekannte Vorgänge heruntergeladen.
• Privilegienänderungen: Ein Benutzer erhält unerwartet Zugang zu Datenbeständen außerhalb seiner Aufgaben.
• Externe Speicherziele: Dokumente werden an bisher nicht verwendete Cloudkonten übertragen.
• Unberechtigte Kontoaktivität: Anmeldungen oder API-Aktionen lassen sich keinem regulären Dienstauftrag zuordnen.
• Legitime Alternativen: Genehmigte Backups, Kundenexporte und Projektaustausch müssen geprüft werden.

Wie wird ein möglicher Datendiebstahl untersucht?

Die technische Aufklärung beginnt mit den betroffenen Dateien, den tatsächlichen Zugriffsrechten und dem bekannten Zeitraum. Audit- und Anwendungsprotokolle sollten nachvollziehbar gesichert werden. Der Inhalt der Daten kann für die Risikobewertung wichtig sein; eine unnötige Weiterverbreitung sensibler Unterlagen während der Untersuchung ist zu vermeiden.

Die Untersuchung muss unterscheiden, ob eine Datei lediglich erreichbar war, tatsächlich aufgerufen oder nachweislich übertragen wurde. Manche Systeme protokollieren nicht jeden einzelnen späteren Lesevorgang. Solche Beweisgrenzen müssen im Bericht erkennbar bleiben.

Bei personenbezogenen Daten kommen die Pflichten nach der DSGVO in Betracht. Bei möglicherweise betroffenen Geschäftsgeheimnissen müssen die vorhandenen Geheimhaltungsmaßnahmen und die Berechtigung des Zugriffs dokumentiert werden.

Welche Gegenmaßnahmen erschweren Datendiebstahl?

Unternehmen können den Datenzugriff nach tatsächlichen Aufgaben begrenzen. Cloudfreigaben und externe Übertragungen sollten nachvollziehbar verwaltet werden. Technische Lösungen zur Verhinderung unerlaubter Datenabflüsse können bestimmte Muster erkennen, ersetzen aber keine klare Rechtevergabe.

• Vertrauliche Datenbestände und zuständige Eigentümer dokumentieren.
• Zugriff und Exportrechte auf erforderliche Personen und Dienste beschränken.
• Externe Cloudfreigaben und ungewöhnliche Datenbewegungen kontrollieren.
• Bei Rollenwechseln nicht mehr benötigte Zugänge entziehen.
• Sensible Geschäftsdaten mit angemessenen Geheimhaltungsmaßnahmen schützen.
• Bei bestätigtem Vorfall Daten- und Kontofolgen unabhängig voneinander prüfen.

Welche rechtlichen Vorschriften gelten?

§ 4 GeschGehG enthält Verbote des unbefugten Erlangens, Verwendens und Offenlegens von Geschäftsgeheimnissen. Ob Informationen entsprechend geschützt sind, richtet sich nach der Definition des § 2 GeschGehG. § 5 enthält bestimmte Ausnahmen für berechtigte Interessen, etwa bei der Aufdeckung von Fehlverhalten unter den gesetzlichen Voraussetzungen.

Bei einem unberechtigten Zugriff auf besonders geschützte Daten kann § 202a StGB zur Prüfung stehen. Handelt es sich um personenbezogene Informationen, sind die DSGVO-Regeln zu Datenverletzungen gesondert anzuwenden. Nicht jede unberechtigte Kopie erfüllt automatisch sämtliche genannten Tatbestände.

Datendiebstahl ohne sichtbaren Systemausfall

Unternehmen können einen unberechtigten Datenabfluss übersehen, wenn die betroffenen Anwendungen weiter funktionieren. Bei einem kopierten Kundenexport bleibt der ursprüngliche Datensatz häufig vollständig erhalten. Auch ein Angreifer, der vertrauliche Dokumente aus einem Cloudspeicher herunterlädt, muss die Dateien nicht verändern oder den Dienst sperren. Die fehlende Störung des Geschäftsbetriebs ist daher kein Beleg, dass keine Informationen abgeflossen sind.

Anders ist die Lage bei einer Datenverschlüsselung oder Löschung, die den Zugriff für berechtigte Nutzer verhindert. Hier kann neben dem Verlust der Vertraulichkeit auch die Verfügbarkeit der Informationen betroffen sein. Die europäische Datenschutzaufsicht unterscheidet bei Datenschutzverletzungen zwischen Vertraulichkeit, Integrität und Verfügbarkeit. Diese Kategorien helfen bei der technischen und rechtlichen Bewertung, sind aber keine eigenständigen Strafnormen.

Welche Zugriffswege werden bei einem Verdacht geprüft?

Übernommene Benutzerkonten

Ein gültiger Login kann von einer fremden Person verwendet werden, nachdem Zugangsdaten durch Phishing oder aus einer früheren Datenpanne bekannt geworden sind. Für eine Untersuchung sind der Zeitraum des verdächtigen Zugriffs, die zugeordneten Berechtigungen und die tatsächlich dokumentierten Datenabrufe von Interesse. Eine ungewöhnliche Anmeldung beweist für sich noch keine Entwendung bestimmter Dateien.

Cloudfreigaben und verbundene Anwendungen

Gemeinsame Ordner, freigegebene Links und externe Apps können den Zugriff auf vertrauliche Informationen eröffnen. Manche Freigaben waren zunächst für ein Projekt berechtigt und wurden nach dessen Abschluss nicht beendet. Eine solche Konfiguration muss zunächst auf ihre tatsächliche Reichweite geprüft werden. Ein bloß öffentlich erreichbarer Link beweist nicht, dass eine fremde Person die Daten heruntergeladen hat.

Missbrauch vorhandener Mitarbeiterrechte

Eine berechtigte Person kann Informationen außerhalb des erlaubten Geschäftszwecks verwenden oder an einen Dritten weitergeben. Dabei liegt nicht zwangsläufig eine technische Überwindung von Zugangssicherungen vor. Bei einem Verdacht sind die arbeitsrechtlichen, datenschutzrechtlichen und strafrechtlichen Grenzen einer internen Untersuchung zu beachten. Ein großer Export durch einen Mitarbeiter kann auch einem legitimen Geschäftsprozess entsprechen.

Angriffe auf Dienstleister und Schnittstellen

CRM-Systeme, Newsletterdienste und Softwareanbieter verarbeiten häufig Daten für mehrere Unternehmen. Ein Vorfall bei einem Dienstleister kann Auswirkungen auf angeschlossene Kunden haben. Für eine belastbare Zuordnung muss festgestellt werden, welche Daten der Dienstleister speichern oder abrufen konnte und ob genau diese Informationen betroffen sind. Eine allgemeine Sicherheitsmeldung ohne Kenntnis des Datenumfangs rechtfertigt keine Behauptung, sämtliche Kundendaten seien gestohlen worden.

Wie wird ein möglicher Datenabfluss nachgewiesen?

Die Untersuchung beginnt mit einer zeitlichen Rekonstruktion. Dazu können Anmeldeereignisse, Cloud-Auditprotokolle, Dateiabrufe, Exporthistorien und vorhandene Netzwerkaufzeichnungen gehören. Der Zeitpunkt, zu dem ein Vorfall entdeckt wurde, ist nicht zwingend der Zeitpunkt des ersten unbefugten Zugriffs. Eine Zeitangabe sollte deshalb mit ihrer Quelle und gegebenenfalls der verwendeten Zeitzone dokumentiert werden.

Ein hoher ausgehender Datenverkehr kann ein Untersuchungsansatz sein. Er könnte aber auch auf eine zulässige Datensicherung, eine Videokonferenz oder gewöhnliche Synchronisierung zurückgehen. Eine bestätigte Übertragung an einen externen Dienst zeigt noch nicht automatisch, welche konkreten Dateien übertragen wurden. Technische Befunde müssen mit den tatsächlichen Geschäftsabläufen abgeglichen werden.

Bei einer Untersuchung können Originalprotokolle und ihre Aufbewahrungsdauer für die zeitliche Zuordnung benötigt werden. Eine spätere Änderung oder unkontrollierte Bereinigung der betroffenen Systeme kann Hinweise beseitigen. Die NIST-Empfehlungen zur Incident Response (SP 800-61 Rev. 3) beschreiben die abgestimmte Behandlung von Sicherheitsvorfällen, vom Erkennen über Eindämmung und Ursachenbeseitigung bis zur Wiederherstellung.

Welche Pflichten können bei personenbezogenen Daten entstehen?

Bei einer Verletzung des Schutzes personenbezogener Daten sind die Voraussetzungen der DSGVO gesondert zu prüfen. Nach Artikel 33 muss der Verantwortliche die zuständige Aufsichtsbehörde ohne unangemessene Verzögerung und möglichst innerhalb von 72 Stunden nach Bekanntwerden benachrichtigen, sofern die Verletzung voraussichtlich nicht ohne Risiko für die Rechte und Freiheiten natürlicher Personen bleibt. Die Frist beginnt nicht pauschal mit dem ersten technischen Verdachtsmoment, sondern ist anhand der maßgeblichen Kenntnis der Verletzung zu beurteilen.

Artikel 34 betrifft die Benachrichtigung betroffener Personen bei einem voraussichtlich hohen Risiko. Beide Vorschriften haben unterschiedliche Voraussetzungen und Ausnahmen. Nicht jeder Diebstahl eines Geschäftsgeheimnisses ist automatisch ein meldepflichtiger personenbezogener Datenschutzvorfall. Die Hinweise des Europäischen Datenschutzausschusses erläutern die Abgrenzung und die Anforderungen an Dokumentation und Meldung.

Die Information betroffener Kunden sollte die bestätigten Datenkategorien, bekannte Folgen und geeignete Schutzschritte nennen. Unklare Punkte sind als vorläufig zu kennzeichnen. Ein Unternehmen sollte weder Entwarnung geben, bevor der Umfang geklärt ist, noch einen vollständigen Datenabfluss behaupten, den es bislang nicht belegen kann.

Wie können Geschäftsgeheimnisse betroffen sein?

Bei gestohlenen Preislisten, technischen Zeichnungen oder nichtöffentlichen Vertriebsunterlagen kann das Geschäftsgeheimnisgesetz Bedeutung haben. Ein Geschäftsgeheimnis setzt unter anderem voraus, dass die Information nicht allgemein bekannt oder ohne Weiteres zugänglich ist, wirtschaftlichen Wert wegen ihrer Geheimhaltung besitzt und Gegenstand angemessener Geheimhaltungsmaßnahmen war. Nicht jedes interne Dokument erfüllt diese Merkmale automatisch.

Eine mögliche Verletzung kann nach den gesetzlichen Voraussetzungen zivilrechtliche Ansprüche und in bestimmten Fällen strafrechtliche Folgen haben. Für eine Untersuchung müssen die ursprünglichen Zugangsberechtigungen, vereinbarte Vertraulichkeit und konkrete Nutzung der Informationen festgestellt werden. Ein allgemeiner Vermerk „vertraulich“ ersetzt nicht die Prüfung der Schutzvoraussetzungen.

Was unterscheidet eine Löschung beim Anbieter von der Schadensbegrenzung?

Wird ein gestohlener Datenbestand auf einer Website veröffentlicht, kann der konkrete Inhalt beim zuständigen Hostingdienst gemeldet werden. Die Entfernung dieser Fundstelle verhindert aber nicht, dass unbefugte Personen eine bereits vorhandene Kopie besitzen. Eine Suchmaschinen-Auslistung beseitigt den Datensatz auf einem fremden Server ebenso wenig.

Für sensible Zugänge sind möglicherweise Passwortwechsel, das Sperren bestimmter Sitzungen oder die Änderung von API-Berechtigungen nötig. Bei veränderten Daten muss die Integrität aus verlässlichen Sicherungen geprüft werden. Diese technischen Maßnahmen sind von einer rechtlichen Meldung oder einer öffentlichen Richtigstellung zu unterscheiden.

Welche Auswirkungen kann Datendiebstahl auf Vertrieb und Reputation haben?

Ein abgeflossener CRM-Export kann Namen, geschäftliche E-Mail-Adressen, Vertragsphasen oder vertrauliche Konditionen enthalten. Dritte könnten diese Angaben verwenden, um glaubwürdige Nachrichten im Namen eines Vertriebspartners zu versenden. Dass nach einem Datenvorfall eine verdächtige Nachricht auftaucht, beweist noch keinen direkten Zusammenhang; die tatsächliche Datenherkunft ist gesondert zu prüfen.

Für die Kundenkommunikation sind bestätigte Fakten und eine erreichbare Ansprechstelle hilfreich. Pauschale Sicherheitsversprechen können die spätere Aufarbeitung erschweren. Eine sachliche Chronologie der bestätigten Zugriffe, getroffenen Maßnahmen und offenen Punkte schafft eine prüfbare Grundlage für die weitere Bearbeitung.

Häufige Fragen zu Data Theft

Kann ein Diebstahl stattfinden, obwohl die Originaldatei unverändert vorhanden ist?

Ja. Beim Kopieren bleiben Dateien häufig im Originalsystem bestehen.

Ist jeder Export von Kundendaten unberechtigt?

Nein. Unternehmen können mit entsprechender Rechtsgrundlage und Berechtigung Daten rechtmäßig exportieren.

Ist ein öffentlich zugänglicher Speicher immer das Ergebnis eines Hackers?

Nein. Eine Fehlkonfiguration kann Daten auch ohne fremden technischen Eingriff erreichbar machen.

Wo können betroffene Unternehmen Hilfe erhalten?

Bei Verdacht auf entwendete Unternehmensinformationen sollten IT-Sicherheit und die zuständigen Datenschutz- beziehungsweise Rechtsfachleute die betroffenen Daten und Berechtigungen prüfen. BRANDPROTECTIONNOW begleitet Unternehmen bei der Dokumentation digitaler Folgeangriffe, der Untersuchung missbräuchlicher öffentlicher Unternehmensdarstellungen und der Abstimmung technischer Maßnahmen mit spezialisierten Security-Partnern. Für mögliche Reputationsfolgen informiert BRANDPROTECTIONNOW zum Reputationsschutz.

Fachquellen

• MITRE ATT&CK – Transfer Data to Cloud Account (T1537): Cloudbasierte Datenübertragung.
• MITRE ATT&CK – Exfiltration Over C2 Channel (T1041): möglicher Datenabfluss.
• § 2 GeschGehG, § 4 GeschGehG und § 5 GeschGehG: Schutz und gesetzliche Ausnahmen.
• DSGVO: Vorgaben bei personenbezogenen Daten.

Database Leak bezeichnet die unberechtigte Offenlegung oder öffentliche Zugänglichkeit von Datenbankinhalten. Das kann eine vollständige Datenbank, einen Backupstand oder einen exportierten Auszug betreffen. Ein Leak kann durch einen externen Angriff, eine fehlerhafte Zugriffskonfiguration oder die versehentliche Veröffentlichung einer Datei entstehen.

Der Begriff wird im Alltag teilweise für jeden Datenabfluss verwendet. Für die technische und rechtliche Prüfung muss genauer festgestellt werden, ob Daten tatsächlich öffentlich erreichbar, an unberechtigte Empfänger übermittelt oder lediglich auf einem falsch konfigurierten System vorhanden waren. Nicht jede Datenbankstörung ist automatisch eine Veröffentlichung vertraulicher Informationen.

Welche Ursachen kann ein Database Leak haben?

Fehlkonfigurierte Cloudspeicher

Ein Unternehmen legt einen Datenbankexport in einem Cloudspeicher ab. Wenn die Zugriffsregeln falsch gesetzt sind, kann die Datei außerhalb des vorgesehenen Personenkreises erreichbar werden. Ein solcher Fehler setzt nicht zwingend den Zugriff eines Hackers auf ein Administrationskonto voraus.

Unzureichend abgesicherte Datenbankdienste

Bestimmte Datenbanksysteme können über Netzwerkschnittstellen angesprochen werden. Eine versehentlich öffentlich erreichbare Verwaltungsfunktion kann unberechtigte Zugriffe begünstigen. Ob tatsächlich Daten lesbar waren, hängt von Authentisierung und den eingerichteten Berechtigungen ab. Die bloße Erreichbarkeit eines Netzwerkports genügt nicht für eine Aussage über den Inhalt.

Öffentlich abgelegte Backups

Sicherungsdateien können Kundendaten, Zugangsinformationen oder andere sensible Inhalte enthalten. Werden sie in einem öffentlich erreichbaren Ordner gespeichert, entsteht ein mögliches Offenlegungsproblem. Ein Backup darf nicht allein deshalb als unproblematisch eingestuft werden, weil die produktive Datenbank weiterhin geschützt ist.

Versehentliche Exportfreigaben

Eine interne Auswertung kann als Datei exportiert und über eine zu weit gefasste Freigabe verfügbar gemacht werden. Das ist eine andere Ursache als ein gezielter Angriff. Für die Risikoprüfung zählen die tatsächlichen Empfänger und betroffenen Datenarten.

Gestohlene Zugangsdaten

Ein Angreifer kann ein reguläres Verwaltungskonto übernehmen und daraus Daten kopieren. Der spätere öffentliche Leak kann dann Folge von Data Theft sein. Die fremde Veröffentlichung beweist jedoch nicht allein, wie das ursprüngliche Konto kompromittiert wurde.

Missbrauch von Schnittstellen

Eine Anwendung kann über eine API Zugriff auf Daten gestatten. Fehlerhafte Berechtigungsprüfungen können dazu führen, dass Informationen anderer Kunden abrufbar werden. Für die Bewertung müssen die tatsächliche Funktionsweise und der Umfang der zugänglichen Daten geprüft werden.

Database Leak, Data Breach und Data Theft unterscheiden

Data Breach bezeichnet im Sinne der DSGVO die Verletzung der Sicherheit personenbezogener Daten. Dazu können unbeabsichtigte Offenlegung, Verlust oder Änderung gehören. Ein Database Leak mit personenbezogenen Daten kann eine solche Verletzung darstellen.

Data Theft beschreibt gezieltes unberechtigtes Kopieren oder Entwenden von Informationen. Nicht jeder öffentlich erreichbare Datenbankexport wurde absichtlich gestohlen. Umgekehrt kann ein Angreifer Daten kopieren, ohne sie anschließend öffentlich zu verbreiten.

Diese Abgrenzung ist für die Ermittlung des Eintrittswegs wichtig. Eine falsch konfigurierte Speicherfreigabe verlangt andere technische Korrekturen als eine kompromittierte Benutzeridentität.

Welche Informationen können von einem Leak betroffen sein?

Ein Datenbankauszug kann persönliche Adressen, Telefonnummern, Bestellhistorien oder Geschäftsinformationen enthalten. In manchen Fällen sind Zugangsdaten oder andere technische Geheimnisse betroffen. Die tatsächliche Gefährdung hängt von der Art der Informationen, ihrer Aktualität und dem vorhandenen Schutz ab.

Bei Zugangsdaten ist zu unterscheiden, ob Passwörter im Klartext, durch ein Hashverfahren geschützt oder überhaupt nicht Bestandteil des Exports waren. Eine pauschale Behauptung über sofort übernehmbare Konten wäre ohne Kenntnis des Speicherverfahrens unzutreffend.

Auch Kundendaten mit geringer technischer Sensibilität können Personen betreffen, etwa wenn sie vertrauliche Kauf- oder Gesundheitsinformationen enthalten. Die Folgen dürfen nicht allein aus der Dateigröße geschätzt werden.

Ein fiktiver Vorfall bei einem Versandhändler

Ein Versandunternehmen entdeckt, dass ein für eine frühere Analyse angelegter Datenbankexport über eine nicht vorgesehene öffentliche Adresse erreichbar war. Die Datei enthält Kundennamen, Lieferadressen und Bestellnummern. Die IT entfernt die öffentliche Freigabe kontrolliert und sichert vorhandene Zugriffsprotokolle.

Die Untersuchung muss nun klären, wie lange die Datei erreichbar war und ob Hinweise auf Zugriffe vorliegen. Das Unternehmen bewertet die Gefährdungen für die betroffenen Kunden und dokumentiert den Vorgang. Ein fehlender öffentlich nachweisbarer Download bedeutet nicht automatisch, dass keinerlei Datenoffenlegung möglich gewesen wäre.

Eine Meldung nach der DSGVO kann je nach Risikobewertung erforderlich sein. Die bloße Sichtbarkeit der Datei im internen Speicher ist dagegen nicht automatisch derselbe Sachverhalt.

Woran kann ein Database Leak erkannt werden?

Hinweise können von Sicherheitsmeldungen, internen Kontrollen oder externen Hinweisen auf öffentlich erreichbare Daten stammen. Ein angebliches Verkaufsangebot mit einer Firmendatenbank beweist aber nicht automatisch die Echtheit des angebotenen Materials. Solche Behauptungen müssen vorsichtig geprüft werden, ohne Daten aus zweifelhaften Quellen weiterzuverbreiten.

• Speicherfreigaben: Vertrauliche Exporte oder Backups besitzen unerwartete öffentliche Berechtigungen.
• Ungewöhnliche Downloads: Protokolle zeigen nicht autorisierte Zugriffe oder großvolumige Abfragen.
• Verwaltungsänderungen: Benutzerkonten oder Freigaberegeln wurden ohne dokumentierte Freigabe verändert.
• Externe Hinweise: Ein Dritter meldet eine konkrete öffentliche Datenquelle.
• Dateninhalt: Die tatsächlich erreichbaren Informationen müssen einer Schutzklasse zugeordnet werden.
• Alternative Erklärungen: Reguläre Testdaten und bewusst veröffentlichte offene Datensätze sind zu berücksichtigen.

Was sollten Unternehmen nach einem bestätigten Leak tun?

Der öffentliche Zugang muss eingegrenzt werden. Vor dem Entfernen vorhandener Informationen sollten die nötigen technischen Belege gesichert werden. Danach muss die Ursache geklärt werden, damit eine erneute Freigabe oder ein weiterhin kompromittiertes Konto nicht bestehen bleibt.

• Die betroffene Datenquelle und alle zugehörigen Freigaben feststellen.
• Unberechtigte Erreichbarkeit kontrolliert beenden.
• Zugriffs- und Änderungshistorie soweit vorhanden sichern.
• Betroffene Datenarten und Personengruppen nachvollziehbar erfassen.
• Mögliche kompromittierte Konten und API-Zugänge gesondert prüfen.
• Rechtliche Melde- und Informationspflichten anhand des tatsächlichen Risikos beurteilen.

Die Entfernung einer Datei aus einem Cloudspeicher garantiert nicht, dass bereits vorhandene fremde Kopien verschwinden. Auch eine Löschaufforderung an eine Plattform kann die Verbreitung nicht vollständig rückgängig machen.

Welche Anforderungen gelten nach der DSGVO?

Bei personenbezogenen Daten kann ein Database Leak eine Verletzung des Schutzes personenbezogener Daten nach Artikel 4 Nr. 12 DSGVO sein. Nach Artikel 33 DSGVO muss der Verantwortliche eine meldepflichtige Verletzung unter den gesetzlichen Voraussetzungen unverzüglich und möglichst binnen 72 Stunden ab Bekanntwerden an die zuständige Aufsichtsbehörde melden, sofern die gesetzliche Ausnahme für voraussichtlich fehlendes Risiko nicht greift.

Artikel 34 DSGVO verlangt unter den dort genannten Voraussetzungen die Benachrichtigung betroffener Personen, wenn voraussichtlich ein hohes Risiko für ihre Rechte und Freiheiten besteht. Die Schwellen der beiden Vorschriften sind nicht identisch. Eine pauschale Pflicht zur öffentlichen Benachrichtigung aller Nutzer folgt aus dem Begriff Database Leak allein nicht.

Für bestimmte Einrichtungen können nach dem seit Dezember 2025 geänderten BSIG gesonderte Meldepflichten bestehen. Ob eine konkrete Einrichtung und ein konkreter Vorfall erfasst werden, ist eigenständig zu prüfen.

Wie lässt sich ein erneuter Leak vermeiden?

Unternehmen sollten Datenbankexports und Sicherungen mit denselben Schutzüberlegungen behandeln wie produktive Daten. Externe Freigaben müssen dokumentiert und nach Ende des jeweiligen Geschäftsprozesses überprüft werden. Test- und Entwicklungsumgebungen dürfen keine unkontrollierten Kopien echter Kundendaten enthalten.

Geeignete technische Kontrollen können unerwartete öffentliche Freigaben, ungewöhnliche Downloads und Änderungen von Berechtigungen sichtbar machen. Die Prüfregeln müssen zum verwendeten Cloud- oder Datenbanksystem passen.

Was bedeutet eine öffentlich erreichbare Datenbank technisch?

Eine Datenbank kann Informationen über das Internet bereitstellen, obwohl die Betreiber dies nicht beabsichtigt haben. Ursache kann eine fehlende Zugangsbeschränkung, eine falsch konfigurierte Netzfreigabe oder ein ungeeigneter Export in einen öffentlich zugänglichen Speicher sein. Nicht jede Datenbank, die eine öffentliche IP-Adresse besitzt, ist damit ungeschützt: Manche Systeme lassen Verbindungen nur aus definierten Netzen zu oder verlangen zusätzliche Authentifizierung.

Ein offen zugänglicher Weblink zu einer Datei ist nicht dasselbe wie eine direkt erreichbare Datenbank. Im ersten Fall wird möglicherweise ein einzelner Export über eine Website ausgeliefert. Im zweiten Fall kann ein Datenbankdienst selbst angesprochen werden. Für eine fachliche Untersuchung sind die tatsächlich erreichbaren Funktionen und die Berechtigungen zu unterscheiden. Die Prüfung fremder Systeme ohne Auftrag oder Erlaubnis kann rechtliche Grenzen überschreiten.

Wie können Daten durch Sicherungen und Exporte sichtbar werden?

Fehlplatzierte Sicherungsdateien

Eine technische Sicherung enthält häufig mehr Informationen als die öffentlich sichtbare Anwendung. In einer Datenbankkopie können Kundendaten, interne Kennungen und nicht veröffentlichte Einstellungen gespeichert sein. Wird sie in einen frei abrufbaren Webordner verschoben, ist ihre Schutzwirkung möglicherweise aufgehoben. Ob Dritte darauf zugreifen konnten, muss getrennt untersucht werden.

Falsch eingestellte Cloud-Berechtigungen

Cloudspeicher erlauben unterschiedlichen Nutzergruppen und technischen Diensten Zugriff auf Objekte. Ein für ein Team bestimmter Ordner kann durch eine fehlerhafte Freigabe öffentlich erreichbar werden. Die Erkennung einer solchen Fehlkonfiguration ist kein Beweis für einen durchgeführten Download. Für die Bewertung können vorhandene Zugriffsprotokolle, Zeitpunkt und Dauer der Freigabe sowie die betroffenen Inhalte von Bedeutung sein.

Testsysteme und alte Datenbestände

Bei Entwicklungs- und Testumgebungen können Kopien echter Kundendaten verwendet worden sein. Wird ein Testsystem ohne geeignete Schutzmaßnahmen ins Internet gestellt, kann ein eigenständiger Datenvorfall entstehen. Eine deaktivierte Produktionsdatenbank ist nicht automatisch ungefährlich, wenn alte Exporte weiterhin auf einem anderen Server zugänglich sind.

Wann liegt ein „Leak“ vor, wann eine bestätigte Entwendung?

Der Ausdruck Database Leak wird oft für unbeabsichtigt offengelegte Datenbestände verwendet. Data Theft bezeichnet dagegen eine unberechtigte Entwendung oder Aneignung, die nicht zwingend durch eine Fehlkonfiguration ausgelöst wird. Bei einem Data Breach steht die Verletzung der Datensicherheit im Vordergrund. Diese Begriffe können denselben Sachverhalt betreffen, haben aber unterschiedliche Schwerpunkte.

Eine Datenbank kann über längere Zeit ungeschützt erreichbar gewesen sein, ohne dass ein tatsächlicher fremder Abruf nachgewiesen ist. Umgekehrt kann ein Angreifer einen Datensatz über gestohlene Berechtigungen kopiert haben, obwohl die Freigaberegeln technisch korrekt eingerichtet waren. Eine öffentliche Darstellung sollte deshalb zwischen „zugänglich“, „abgerufen“ und „veröffentlicht“ unterscheiden.

Wie wird der Umfang eines Database Leak bestimmt?

Zu Beginn einer Untersuchung sollte geklärt werden, welche konkreten Datenbestände betroffen waren. Enthält der Fund nur öffentlich sichtbare Artikel oder auch Kundenanschriften, Auftragsinformationen und vertrauliche Dateien? Welche Datenfelder sind personenbezogen? Welche Einträge stammen aus einem historischen Backup? Eine bloße Größenangabe in Megabyte beantwortet diese Fragen nicht.

Bei einer technischen Prüfung sind Dateinamen, Metadaten, Exportzeitpunkte, Berechtigungen und vorhandene Zugriffsprotokolle mögliche Untersuchungsgegenstände. Die Auswertung darf die Daten nicht ohne Notwendigkeit weiter kopieren oder an weitere Systeme übertragen. Die Aufbewahrung sensibler Dateien muss auf den erlaubten Untersuchungszweck begrenzt bleiben.

Die Dauer der möglichen Offenlegung ist nicht automatisch mit dem Datum des ersten gefundenen Suchtreffers identisch. Eine Datei kann schon zuvor erreichbar gewesen sein oder erst nach einem technischen Fehler kurzzeitig öffentlich geworden sein. Zeitstempel, Änderungsprotokolle und Konfigurationshistorien können zur Eingrenzung beitragen.

Was ist nach dem Entdecken einer offenen Datenbank zu tun?

Ein Betreiber kann den unberechtigten Zugriff durch geeignete Berechtigungen, Netzregeln oder die Entfernung einer öffentlichen Kopie begrenzen. Dabei ist zu vermeiden, dass die schnelle Bereinigung alle für die Untersuchung notwendigen Spuren vernichtet. Vorhandene Logdaten und Konfigurationen können, soweit rechtlich und technisch geeignet, dokumentiert werden. Bei bestätigten gestohlenen Zugangsdaten sind auch deren weitere Nutzungsmöglichkeiten zu prüfen.

Der Vorfall sollte anschließend hinsichtlich Ursache, möglichem Datenzugriff und Konsequenzen bewertet werden. Die NIST-Empfehlungen für Incident Response behandeln Eindämmung, Ursachenbeseitigung, Wiederherstellung und die Abstimmung der beteiligten Verantwortlichen. Ein reines Abschalten der offenen URL ersetzt keine Untersuchung des ursprünglichen Fehlers.

Welche DSGVO-Pflichten können entstehen?

Sind personenbezogene Daten betroffen, kann eine Verletzung des Schutzes personenbezogener Daten vorliegen. Die DSGVO erfasst hierbei nicht allein den bestätigten Diebstahl. Nach den Hinweisen des Europäischen Datenschutzausschusses können auch versehentliche Offenlegungen oder unberechtigte Zugriffsmöglichkeiten den Schutz der Vertraulichkeit betreffen. Die konkrete datenschutzrechtliche Einordnung hängt von den Feststellungen zum Sicherheitsvorfall ab.

Artikel 33 DSGVO kann eine Meldung an die zuständige Aufsichtsbehörde verlangen. Die Regel nennt die möglichst innerhalb von 72 Stunden nach Bekanntwerden zu erfüllende Meldung, sofern der Vorfall voraussichtlich nicht ohne Risiko für die Rechte und Freiheiten natürlicher Personen bleibt. Bei hohem Risiko kann nach Artikel 34 die Information betroffener Personen erforderlich sein. Eine pauschale Pflicht, bei jeder versehentlich öffentlich liegenden Datei alle Kunden zu benachrichtigen, wäre unzutreffend.

Eine Risikobewertung berücksichtigt Art und Umfang der Daten, mögliche betroffene Personen, die Dauer der Offenlegung und vorhandene Schutzmechanismen. Diese Faktoren ersetzen keine gesetzliche Prüfung, helfen aber bei der nachvollziehbaren Einordnung. Ein fehlender Nachweis fremder Downloads beseitigt die Frage nach einer möglichen Datenschutzverletzung nicht automatisch.

Was geschieht, wenn Suchmaschinen eine offen gelegte Datei erfasst haben?

Ein öffentlicher Export kann über eine Suchmaschine auffindbar gewesen sein. Wird er später aus dem Speicher entfernt, kann unter Umständen noch ein veralteter Suchtreffer oder ein Textausschnitt sichtbar bleiben. Das Verfahren zur Aktualisierung veralteter Google-Inhalte kann dann eine eigene Maßnahme sein. Die ursprüngliche Löschung beim Anbieter und die Indexaktualisierung sind voneinander zu trennen.

Hat ein Dritter die Daten auf einer neuen Website veröffentlicht, genügt eine Indexaktualisierung der Original-URL nicht. Für jede bestätigte fremde Veröffentlichung können gesonderte Meldungen erforderlich werden. Eine Löschbestätigung bei einer Suchmaschine ist kein Nachweis, dass keine privaten Kopien mehr existieren.

Wie lässt sich ein ähnlicher Vorfall vermeiden?

Zugriffsrechte sollten für Produktionsdaten, Testumgebungen und Backups getrennt vergeben werden. Freigaben, die für ein zeitlich begrenztes Projekt eingerichtet werden, können nach Abschluss überprüft und geschlossen werden. Auch externe Integrationen und Dienstleisterzugänge gehören zur Berechtigungsverwaltung.

Bei Tests mit echten personenbezogenen Daten ist zu prüfen, ob diese Verwendung zulässig und erforderlich ist. Soweit möglich können nichtproduktive Umgebungen mit geeigneten Testdaten arbeiten. Öffentliche Exporte sollten keine geheimen Anmeldeschlüssel oder private Datensätze enthalten, die für den vorgesehenen Zweck nicht benötigt werden.

Welche Folgen können Datenlecks für Vertrieb und Kundenbeziehungen haben?

Enthält ein öffentlich gewordener CRM-Export Ansprechpartner, Verhandlungsstände oder individuell vereinbarte Konditionen, können Dritte daraus glaubwürdige Täuschungsnachrichten erstellen. Der tatsächliche Missbrauch muss aber nachgewiesen werden. Nicht jede spätere Phishing-Mail ist automatisch durch genau diesen Leak verursacht.

Eine sachliche Kundeninformation benennt bestätigte Datenkategorien und den Stand der Untersuchung. Unbelegte Entwarnung kann ebenso problematisch sein wie die unbegründete Behauptung eines vollständigen Datendiebstahls. Anfragen von Betroffenen sollten über einen überprüfbaren offiziellen Kontaktweg bearbeitet werden.

Häufige Fragen zu Database Leak

Ist ein öffentlich erreichbares Backup automatisch ein Hackerangriff?

Nein. Die Ursache kann auch eine versehentliche Freigabe sein.

Muss ein Leak mit Kundendaten immer allen Kunden gemeldet werden?

Nein. Artikel 33 und 34 DSGVO enthalten unterschiedliche Voraussetzungen und Risikoschwellen.

Verschwindet ein Leak nach dem Löschen der Originaldatei?

Nicht zwangsläufig. Bereits erstellte fremde Kopien können weiterbestehen.

Wo können betroffene Unternehmen Hilfe erhalten?

Bei einer offengelegten Datenbank sollten Unternehmen die IT-Sicherheit und die zuständigen Datenschutzfachleute einbeziehen. BRANDPROTECTIONNOW begleitet Unternehmen bei der Dokumentation möglicher digitaler Folgeangriffe, der Beobachtung missbräuchlicher öffentlicher Darstellungen und der Abstimmung technischer Schutzmaßnahmen mit spezialisierten Partnern. Für mögliche Folgen der Datenveröffentlichung ist BRANDPROTECTIONNOW zum Reputationsschutz der passende Einstieg.

Fachquellen

• DSGVO – Artikel 4 Nr. 12, 33 und 34: Definition und rechtliche Anforderungen.
• MITRE ATT&CK – Transfer Data to Cloud Account: mögliche Datenübertragungen über Cloudfreigaben.
• BSI – NIS-2 und Meldeverfahren: nationale Anforderungen für betroffene Einrichtungen.