Datenpanne: Was du innerhalb von 72 Stunden tun musst

Es passiert schneller, als du denkst

Ein Laptop wird gestohlen. Ein Mitarbeiter schickt eine Kundenliste an die falsche E-Mail-Adresse. Ein Hacker verschafft sich Zugang zu deiner Datenbank. Oder du merkst, dass ein Google Sheet mit Kundendaten monatelang auf "Jeder mit dem Link" gestellt war. Willkommen in der Welt der Datenpannen -- offiziell "Verletzung des Schutzes personenbezogener Daten" nach Art. 4 Nr. 12 DSGVO.

Die Uhr tickt: Ab dem Moment, in dem du von der Datenpanne erfährst, hast du 72 Stunden, um sie bei der österreichischen Datenschutzbehörde (DSB) zu melden -- sofern ein Risiko für die Betroffenen besteht. Und das tut es in den meisten Fällen. Ohne einen vorbereiteten Notfallplan wirst du diese 72 Stunden kaum schaffen. Denn du musst gleichzeitig den Vorfall analysieren, eindämmen, dokumentieren und melden.

Bei Startup Burgenland empfehlen wir jedem Gründungsteam, einen Incident-Response-Plan in der Schublade zu haben -- bevor er gebraucht wird. In diesem Post bekommst du alles, was du dafür brauchst: die rechtlichen Grundlagen, einen konkreten Ablaufplan und Vorlagen für die Meldung.

Was ist eine Datenpanne nach DSGVO?

Art. 4 Nr. 12 DSGVO definiert eine "Verletzung des Schutzes personenbezogener Daten" als eine Verletzung der Sicherheit, die zur Vernichtung, zum Verlust, zur Veränderung oder zur unbefugten Offenlegung von bzw. zum unbefugten Zugang zu personenbezogenen Daten führt -- unabhängig davon, ob sie versehentlich oder unrechtmäßig geschieht.

Datenpannen lassen sich in drei Kategorien einteilen:

Vertraulichkeitsverletzung: Unbefugte erhalten Zugang zu oder Kenntnis von Daten. Beispiele: Kundenliste an falschen E-Mail-Empfänger gesendet, Hackerangriff mit Zugriff auf Datenbank, öffentlich zugängliches Dokument mit personenbezogenen Daten, API-Key im öffentlichen GitHub-Repository.

Integritätsverletzung: Daten werden unbefugt oder versehentlich verändert. Beispiele: Datenbank durch Bug oder Malware korrumpiert, unbefugte Änderung von Kundendaten, Manipulation von Logdaten.

Verfügbarkeitsverletzung: Daten sind vorübergehend oder dauerhaft nicht mehr zugänglich. Beispiele: Ransomware-Angriff, Datenverlust ohne Backup, längerer Systemausfall mit Auswirkungen auf personenbezogene Daten.

Typische Datenpannen in Startups

Wann musst du melden? -- Die Risikobewertung

Nicht jede Datenpanne muss der DSB gemeldet werden. Die Meldepflicht nach Art. 33 Abs. 1 DSGVO greift nur, wenn die Panne "voraussichtlich ein Risiko für die Rechte und Freiheiten natürlicher Personen" darstellt.

Die Risikobewertung berücksichtigt folgende Faktoren:

• Art der Daten: Finanzdaten, Gesundheitsdaten oder Zugangsdaten sind risikoreicher als allgemeine Kontaktdaten
• Umfang: Wie viele Personen und Datensätze sind betroffen?
• Mögliche Konsequenzen: Identitätsdiebstahl, finanzielle Schäden, Diskriminierung, Rufschädigung?
• Besondere Umstände: Sind schutzbedürftige Personen betroffen (Kinder, Patienten)?
• Eindämmung: Konnten die Auswirkungen bereits begrenzt werden?
• Vorsatz: War es ein gezielter Angriff oder ein Versehen?

Im Zweifel: Melden. Die DSB reagiert wohlwollend auf proaktive Meldungen und deutlich strenger auf Meldungen, die erst nach einer Beschwerde durch Betroffene eintreffen. Eine unnötige Meldung hat keine negativen Konsequenzen -- eine unterlassene Meldung kann ein Bußgeld nach sich ziehen (bis EUR 10 Millionen oder 2 % des Jahresumsatzes nach Art. 83 Abs. 4 DSGVO).

Die 72-Stunden-Frist: Art. 33 DSGVO im Detail

Wann beginnt die Frist?

Die 72 Stunden laufen ab dem Zeitpunkt, an dem du als Verantwortlicher "Kenntnis" von der Datenpanne erlangst. Das ist nicht der Zeitpunkt, an dem die Panne passiert ist, sondern der Zeitpunkt, an dem du davon erfahren hast.

Konkrete Szenarien:

• Dein Auftragsverarbeiter meldet dir einen Vorfall: Frist beginnt, sobald du die Meldung erhältst. Wichtig: Dein AVV sollte eine konkrete Meldefrist für den Auftragsverarbeiter enthalten -- idealerweise 24 Stunden
• Du entdeckst den Vorfall selbst: Frist beginnt sofort mit der Entdeckung
• Ein Betroffener oder Dritter informiert dich: Frist beginnt, sobald du die Meldung prüfst und den Vorfall bestätigst
• Medienberichte oder externe Hinweise: Auch hier: sobald du Kenntnis hast

Wie du die Meldung an die DSB machst

Die DSB bietet ein Online-Meldeformular auf dsb.gv.at an. Das ist der schnellste und empfohlene Weg. Alternativ kannst du per E-Mail (dsb@dsb.gv.at) oder postalisch (Barichgasse 40-42, 1030 Wien) melden -- aber bei 72 Stunden Frist ist das Online-Formular die sicherste Wahl.

Pflichtangaben in der Meldung (Art. 33 Abs. 3)

Die Meldung an die DSB muss folgende Informationen enthalten:

1. Art der Datenpanne -- was ist passiert? (Vertraulichkeit, Integrität, Verfügbarkeit)
2. Kategorien und ungefähre Anzahl der betroffenen Personen (z. B. "ca. 500 Kunden")
3. Kategorien und ungefähre Anzahl der betroffenen Datensätze (z. B. "Name, E-Mail, Adresse von ca. 500 Personen")
4. Name und Kontaktdaten des Datenschutzbeauftragten oder einer Anlaufstelle
5. Wahrscheinliche Folgen der Datenpanne (z. B. "Risiko unerwünschter Kontaktaufnahme, kein finanzielles Risiko")
6. Ergriffene oder vorgeschlagene Maßnahmen zur Behebung und Schadensbegrenzung

Wichtig: Du musst nicht alle Informationen sofort komplett haben. Art. 33 Abs. 4 DSGVO erlaubt ausdrücklich eine schrittweise Meldung ("phasenweise Bereitstellung"). Mach die Erstmeldung innerhalb von 72 Stunden mit den bekannten Fakten und liefere Details nach, sobald die Analyse abgeschlossen ist. Das ist völlig legitim und wird von der DSB akzeptiert.

Wann du Betroffene direkt informieren musst -- Art. 34 DSGVO

Zusätzlich zur Meldung an die DSB musst du die betroffenen Personen direkt und unverzüglich informieren, wenn die Datenpanne "voraussichtlich ein hohes Risiko" für deren Rechte und Freiheiten darstellt. Das ist eine höhere Schwelle als die Meldepflicht an die DSB.

Wann liegt ein "hohes Risiko" vor?

• Finanzdaten betroffen (Kreditkartennummern, Bankverbindungen, Zahlungsdaten)
• Gesundheitsdaten betroffen
• Zugangsdaten (Passwörter, Tokens) kompromittiert
• Identitätsdiebstahl ist realistisch möglich
• Besonders schutzbedürftige Personen betroffen (Kinder, Patienten)
• Große Anzahl Betroffener in Kombination mit sensiblen Daten

Was muss in der Benachrichtigung stehen?

• Beschreibung der Datenpanne in klarer, einfacher Sprache (kein Juristendeutsch)
• Name und Kontaktdaten der Ansprechperson in deinem Unternehmen
• Wahrscheinliche Folgen der Panne
• Von dir ergriffene Maßnahmen und konkrete Empfehlungen für die Betroffenen (z. B. "Ändern Sie Ihr Passwort", "Überwachen Sie Ihre Kontoauszüge")

Wann du die Betroffenen NICHT informieren musst

Die Benachrichtigungspflicht entfällt, wenn:

• Die Daten durch Verschlüsselung oder andere Maßnahmen für Unbefugte unlesbar waren (und der Schlüssel nicht kompromittiert ist)
• Du nachträglich Maßnahmen ergriffen hast, die das hohe Risiko beseitigen
• Die individuelle Benachrichtigung unverhältnismäßig aufwändig wäre -- dann genügt eine öffentliche Bekanntmachung (z. B. auf der Website)

Dein Incident-Response-Notfallplan -- Schritt für Schritt

Phase 1: Entdeckung und Eindämmung (Stunde 0--4)

• Vorfall bestätigen: Handelt es sich tatsächlich um eine Datenpanne im Sinne der DSGVO?
• Sofortige Eindämmung: Zugang sperren, kompromittiertes System isolieren, Passwörter ändern, betroffene Accounts sperren
• Beweissicherung: Screenshots anfertigen, Logfiles sichern, E-Mails archivieren -- nichts löschen, was als Beweis dienen könnte
• Incident-Verantwortlichen bestimmen: Wer koordiniert ab jetzt?
• Erste Timeline-Einträge erstellen: Was ist wann passiert?

Phase 2: Analyse und Bewertung (Stunde 4--24)

• Welche Daten sind konkret betroffen? (Kategorien und Umfang)
• Wie viele Personen sind betroffen? (exakt oder geschätzt)
• Was ist die Ursache? (technischer Fehler, menschliches Versagen, Angriff)
• Besteht ein Risiko für die Betroffenen? (Risikobewertung dokumentieren)
• Besteht ein hohes Risiko? (Benachrichtigungspflicht nach Art. 34?)
• Sind Auftragsverarbeiter betroffen oder involviert?
• Wurde der Vorfall bereits eingedämmt oder besteht er fort?

Phase 3: Meldung und Kommunikation (Stunde 24--72)

• Meldung an die DSB vorbereiten (Online-Formular auf dsb.gv.at ausfüllen)
• Meldung absenden -- innerhalb der 72-Stunden-Frist
• Falls hohes Risiko: Benachrichtigung der Betroffenen vorbereiten und versenden
• Geschäftsleitung informieren (falls nicht bereits geschehen)
• Prüfen, ob ein Rechtsanwalt eingeschaltet werden sollte (bei schweren Pannen empfehlenswert)
• Prüfen, ob eine Cyber-Versicherung besteht und der Versicherer informiert werden muss

Phase 4: Nachbereitung (Tage und Wochen danach)

• Vollständige Dokumentation des Vorfalls erstellen
• Ursachenanalyse: Wie konnte es passieren? Welche Schwachstelle wurde ausgenutzt?
• Maßnahmen definieren und umsetzen, um eine Wiederholung zu verhindern
• Nachbericht an die DSB senden (falls die Erstmeldung unvollständig war)
• Team-Debrief: Was lief gut, was muss besser werden?
• Team-Schulung auffrischen (siehe Datenschutz im Team)
• Notfallplan auf Basis der Erfahrungen aktualisieren
• Verarbeitungsverzeichnis und TOMs überprüfen und ggf. anpassen

Dokumentationspflicht -- auch wenn du nicht meldest

Art. 33 Abs. 5 DSGVO verlangt, dass du alle Datenpannen intern dokumentierst -- auch solche, die nicht meldepflichtig sind. Dieses Datenpannen-Register muss die DSB bei einer Prüfung einsehen können.

Für jeden Vorfall dokumentierst du:

• Datum und Uhrzeit des Vorfalls (soweit bekannt)
• Datum und Uhrzeit der Kenntniserlangung
• Art des Vorfalls (Vertraulichkeit, Integrität, Verfügbarkeit)
• Beschreibung des Vorfalls
• Betroffene Daten und Personenkategorien
• Ungefähre Anzahl betroffener Personen und Datensätze
• Folgen des Vorfalls (tatsächliche und potenzielle)
• Ergriffene Sofortmaßnahmen und langfristige Gegenmaßnahmen
• Entscheidung: Meldung an DSB ja/nein -- mit nachvollziehbarer Begründung
• Entscheidung: Benachrichtigung Betroffener ja/nein -- mit Begründung
• Falls gemeldet: Datum der Meldung, Antwort der DSB

Ein einfaches Spreadsheet mit diesen Spalten reicht aus. Bewahre es zusammen mit deinem Verarbeitungsverzeichnis auf.

Was passiert nach der Meldung bei der DSB?

Die DSB wird deine Meldung prüfen und bearbeiten. Mögliche Ergebnisse:

Keine weiteren Maßnahmen: Die DSB bestätigt den Eingang und schließt den Fall. Das ist das häufigste Ergebnis bei kooperativen Meldungen mit angemessenen Gegenmaßnahmen.

Nachfragen: Die DSB fordert weitere Informationen oder eine detailliertere Stellungnahme an. Antworte zeitnah und vollständig.

Anordnungen: Die DSB kann konkrete Maßnahmen anordnen -- z. B. die Benachrichtigung der Betroffenen, wenn du das nicht von selbst getan hast, oder bestimmte technische Schutzmaßnahmen.

Bußgeld: In schweren Fällen, bei Wiederholungen oder bei offensichtlichem Verschulden. Die Kooperationsbereitschaft ist ein wichtiger Faktor bei der Bußgeldbemessung. Proaktive, vollständige Meldungen werden positiv bewertet. Verschwiegene oder verspätete Meldungen führen zu deutlich höheren Strafen.

Praxisbeispiel: Ablauf einer Datenpanne in einem Startup

Damit der Prozess greifbar wird, hier ein konkretes Szenario:

Situation: Am Montagmorgen stellt ein Mitarbeiter fest, dass ein Google Sheet mit 200 Kundendaten (Name, E-Mail, Telefonnummer, Bestellhistorie) seit drei Wochen auf "Jeder mit dem Link kann bearbeiten" gestellt war. Das Dokument wurde in der Zwischenzeit von mehreren Personen aufgerufen -- der Zugriffslog zeigt unbekannte IP-Adressen.

Stunde 0--2: Entdeckung und Eindämmung

• Mitarbeiter informiert sofort die Geschäftsführung (du)
• Zugriffsrechte des Google Sheets werden sofort auf "Nur bestimmte Personen" geändert
• Screenshots vom Zugriffslog und den Freigabe-Einstellungen werden gemacht
• Link-Sharing wird deaktiviert

Stunde 2--12: Analyse

• Welche Daten standen im Sheet? Name, E-Mail, Telefon, Bestellhistorie -- keine Zahlungsdaten, keine Passwörter
• Wie viele Personen betroffen? 200 Kunden
• Wie lange war das Sheet öffentlich? Ca. 3 Wochen
• Zugriffslog zeigt 15 Zugriffe von unbekannten IP-Adressen -- es ist unklar, ob diese Personen die Daten gespeichert oder weiterverbreitet haben
• Risikobewertung: Risiko vorhanden (Kontaktdaten von 200 Personen potenziell exponiert), aber kein hohes Risiko (keine Finanzdaten, keine Gesundheitsdaten, kein Identitätsdiebstahl wahrscheinlich)

Stunde 12--48: Meldung vorbereiten

• DSB-Meldeformular wird ausgefüllt: Art der Panne (Vertraulichkeitsverletzung), ca. 200 betroffene Personen, Kontaktdaten betroffen, Ursache (Fehlkonfiguration der Freigabe-Einstellungen), Maßnahmen (Zugriff gesperrt, Freigabe-Einstellungen überprüft, Team geschult)
• Entscheidung: Meldung an DSB -- ja (Risiko für Betroffene gegeben)
• Entscheidung: Benachrichtigung der Betroffenen -- nein (kein hohes Risiko, da keine sensiblen oder finanziellen Daten betroffen)

Stunde 48--72: Meldung absetzen

• Meldung wird über das Online-Formular der DSB eingereicht
• Bestätigung der DSB wird abgelegt

Tage danach: Nachbereitung

• Alle Google-Dokumente im Unternehmen werden auf Freigabe-Einstellungen geprüft
• Neue Regel: Dokumente mit personenbezogenen Daten dürfen nur mit namentlich benannten Personen geteilt werden
• Team wird nachgeschult (Fokus: Cloud-Freigaben und Need-to-know-Prinzip)
• Eintrag im Datenpannen-Register
• Google Workspace Admin: Warnung bei "Jeder mit dem Link"-Freigaben aktiviert

Cyber-Versicherung -- sinnvoll für Startups?

Eine Cyber-Versicherung kann bei Datenpannen helfen -- sie deckt typischerweise die Kosten für forensische Analyse, Rechtsberatung, Krisenmanagement, Benachrichtigung der Betroffenen und ggf. Bußgelder (soweit versicherbar) ab. Für Startups gibt es mittlerweile erschwingliche Optionen ab ca. EUR 500 bis EUR 2.000 pro Jahr, abhängig von Branche, Umsatz und Datenmenge.

Wann eine Cyber-Versicherung sinnvoll ist:

• Du verarbeitest personenbezogene Daten in größerem Umfang (mehr als 1.000 Datensätze)
• Dein Geschäftsmodell basiert auf Datenverarbeitung (SaaS, Plattform, E-Commerce)
• Du verarbeitest besondere Datenkategorien (Gesundheit, Finanzen)
• Du hast B2B-Kunden, die eine Cyber-Versicherung als Voraussetzung für die Zusammenarbeit verlangen

Was du beachten solltest: Die Versicherung greift in der Regel nur, wenn du angemessene Schutzmaßnahmen getroffen hast. Wenn du keine Passwort-Richtlinien hast, kein Backup machst und dein Team nie geschult wurde, wird der Versicherer die Leistung verweigern. Dokumentierte Schulungen (siehe Datenschutz im Team) und technische Basismaßnahmen sind also auch aus versicherungstechnischer Sicht wichtig.

Vorbereitung: Was du jetzt tun solltest

Warte nicht auf die erste Datenpanne. Bereite dich jetzt vor:

• Notfallkontakte zusammenstellen: DSB (dsb.gv.at, dsb@dsb.gv.at), Rechtsanwalt, IT-Security-Experte, Cyber-Versicherung
• Incident-Response-Plan verschriftlichen: Wer macht was in welcher Reihenfolge?
• Meldewege definieren: Jeder im Team muss wissen, an wen er sich bei einem Verdacht wendet
• DSB-Meldeformular bookmarken: dsb.gv.at -- damit du im Ernstfall nicht erst suchen musst
• Datenpannen-Register anlegen: Ein leeres Spreadsheet mit den richtigen Spalten
• Regelmäßig testen: Einmal pro Jahr einen simulierten Vorfall durchspielen

Fazit und Ausblick

Erstelle jetzt deinen Notfallplan, bevor du ihn brauchst. Drucke die Checkliste aus und lege sie an einen Ort, wo jeder im Team sie findet. Speichere die DSB-Kontaktdaten und das Meldeformular als Lesezeichen. Im nächsten und letzten Post dieser Serie zeigen wir dir, warum Datenschutz-Schulung im Team keine Kür ist -- denn die meisten Datenpannen entstehen durch menschliche Fehler, nicht durch Hacker. Bei Startup Burgenland bekommst du Notfallplan-Vorlagen und Unterstützung im Ernstfall.

Startup Burgenland macht Gründung leistbar: EUR 10.000 Gründungszuschuss (nicht rückzahlbar, keine Eigenkapitalabgabe), 1:1 Coaching und ein Netzwerk aus Steuerberatern, Notaren und Rechtsanwälten. Flexibler Einstieg jederzeit. Schreib uns ein formloses E-Mail.

Über den Autor: Felix Lenhard ist Program Director und Startup Coach bei Startup Burgenland. Zuvor Managing Director beim 360 Innovation Lab, Innovation Manager bei RHI Magnesita und Serial Entrepreneur mit internationalen Exits. Über 15 Jahre Erfahrung in Innovation und Unternehmensaufbau.