Artikel 33 DSGVO setzt die 72-Stunden-Frist für die Meldung von Datenpannen an die Aufsichtsbehörde. Artikel 34 regelt die Benachrichtigung Betroffener. Die Uhr tickt ab „Kenntnisnahme" — wann ist das genau? EDSA Guidelines 9/2022 und BfDI-Orientierungshilfe geben Orientierung.
Dieser Leitfaden erklärt in sieben Abschnitten das regulatorische, technische und operative Bild rund um Datenpannen-Meldeprozess nach Artikel 33 DSGVO: was die Anforderungen konkret sind, wer wann betroffen ist, wie Sie implementieren — und was typische Fehler sind, die DACH-Unternehmen machen.
Wir schreiben aus Implementation-Erfahrung, nicht aus theoretischer Distanz. Innopulse Consulting berät Schweizer und DACH-Unternehmen in DSGVO und revDSG und Softwareengineering, und wir betreiben eigene SaaS-Produkte unter denselben Vorgaben, die wir unseren Kunden empfehlen.
Worum es geht: Kontext und Anwendungsbereich
Artikel 33 DSGVO setzt die 72-Stunden-Frist für die Meldung von Datenpannen an die Aufsichtsbehörde. Artikel 34 regelt die Benachrichtigung Betroffener. Die Uhr tickt ab „Kenntnisnahme" — wann ist das genau? EDSA Guidelines 9/2022 und BfDI-Orientierungshilfe geben Orientierung. Die praktische Frage ist: Wen trifft das konkret, und ab wann? Im Bereich Datenpannen-Meldeprozess nach Artikel 33 DSGVO ist die Antwort selten binär — es gibt einen Anwendungsbereich, in dem die vollen Anforderungen greifen, und Grenzfälle, die Einzelfallprüfung brauchen.
Die folgenden Punkte umreissen den harten Kern dessen, was zu wissen ist:
- 72h ab „Kenntnisnahme" — IT-Security-Ereignis ≠ Kenntnisnahme
- Benachrichtigung Betroffener bei „hohem Risiko" (Artikel 34)
- revDSG Artikel 24: Meldung „so rasch als möglich" an EDÖB
- Risikobewertung nach Vertraulichkeit/Integrität/Verfügbarkeit
Was davon für Ihr Unternehmen kritisch ist, hängt von Grösse, Branche und Kundenstruktur ab. Die folgenden Abschnitte gehen in die Details — wer schnell entscheiden muss, kann zum Abschluss mit den konkreten nächsten Schritten springen.
Rechtsgrundlagen und zeitliche Einordnung
Die DSGVO gilt seit dem 25. Mai 2018 in der gesamten EU. In Deutschland ergänzt das BDSG, in Österreich das DSG, in der Schweiz das revDSG (seit 1. September 2023) den Rahmen. Die Rechtsgrundlagen aus Artikel 6 DSGVO sind zentral: Einwilligung, Vertragserfüllung, rechtliche Verpflichtung, lebenswichtige Interessen, öffentliches Interesse, berechtigtes Interesse.
In der Praxis dominieren zwei Rechtsgrundlagen: Vertragserfüllung bei transaktionalen Prozessen, berechtigtes Interesse bei analytischen und Marketing-Anwendungen mit dokumentierter Abwägung. Einwilligung bleibt für Marketing-Cookies und Newsletter zentral. Das revDSG hat ähnliche Rechtsgrundlagen, formuliert sie aber als Grundsätze in Artikel 6 revDSG statt als Liste. Wer DSGVO-konform arbeitet, deckt in den meisten Fällen auch revDSG ab — aber nicht umgekehrt.
Die konkreten Anforderungen im Detail
Die folgenden Punkte sind der operative Kern von Datenpannen-Meldeprozess nach Artikel 33 DSGVO — das, was tatsächlich in Prozessen, Verträgen und Systemen abgebildet sein muss. Jeder Punkt hat Implementierungskonsequenzen, die über reine Compliance hinausgehen und die Geschäftspraxis formen.
- 72h ab „Kenntnisnahme" — IT-Security-Ereignis ≠ Kenntnisnahme
- Benachrichtigung Betroffener bei „hohem Risiko" (Artikel 34)
- revDSG Artikel 24: Meldung „so rasch als möglich" an EDÖB
- Risikobewertung nach Vertraulichkeit/Integrität/Verfügbarkeit
- Meldung via behördliche Portale (LDI, BfDI, EDÖB)
- Verspätete Meldung ist separater Bussgeldtatbestand
Diese Liste ist nicht abschliessend, aber sie deckt etwa 80% der Fälle ab, die in der Praxis auftauchen. Die restlichen 20% sind Edge-Cases und Branchenspezifika, die Einzelberatung erfordern.
Implementierung in der Praxis
Von der Theorie zur Umsetzung: Datenpannen-Meldeprozess nach Artikel 33 DSGVO erfordert meist mehrere parallele Workstreams. Ein typischer Projektplan sieht drei Phasen:
- Inventarisierung (2-4 Wochen): Ist-Zustand erfassen, betroffene Systeme und Prozesse mappen, Stakeholder identifizieren, Gap-Analyse gegen Anforderungen.
- Design (4-6 Wochen): Zielzustand definieren, Policies ausformulieren, technische Massnahmen spezifizieren, Rollen und Verantwortlichkeiten zuweisen.
- Umsetzung und Betrieb (8-12 Wochen): Implementierung, Testing, Dokumentation, Schulung, Übergang in den Regelbetrieb mit Monitoring und Review-Zyklen.
Die häufigste Falle ist, in Phase 3 zu springen, ohne 1 und 2 sauber abzuschliessen. Die Folge sind inkonsistente Implementierungen, technische Schulden und in der Review sichtbare Compliance-Lücken. Die Investition in die ersten beiden Phasen zahlt sich typischerweise dreifach aus.
Typische Fehler und wie Sie sie vermeiden
Aus Beratungs- und Auditerfahrungen haben sich fünf Fehler als besonders verbreitet herauskristallisiert:
- Rechtsgrundlage nicht pro Verarbeitung dokumentieren — Rechenschaftspflicht nach Artikel 5(2) ist zentral
- Standard-Datenschutzerklärungen aus Generatoren ohne Anpassung verwenden — meist unvollständig
- Consent-Management als Nebensache behandeln — Cookie-Banner sind primäres Abmahn-Ziel
- Betroffenenrechte-Prozess nicht operativ umsetzen — 30-Tage-Frist ist bindend
- AVVs nur einmal abschliessen und nie prüfen — Sub-Processor-Listen ändern sich laufend
Die gute Nachricht: alle fünf sind systematisch vermeidbar. Wer in der Design-Phase diese Punkte explizit adressiert, hat die häufigsten Stolperfallen bereits eliminiert.
Der DACH-Kontext und regionale Unterschiede
In der Schweiz, Deutschland und Österreich gelten teilweise unterschiedliche Regeln und Marktrealitäten. Für Datenpannen-Meldeprozess nach Artikel 33 DSGVO bedeutet das konkret:
- Schweiz: Ausserhalb EU, aber oft über Artikel 2 oder Marktzugang indirekt betroffen. Schweizer Alleinstellung ist selten sinnvoll — die meisten Compliance-Frameworks laufen parallel zu EU-Regimes.
- Deutschland: Strengste Umsetzung der EU-Regeln, aktive Aufsichtsbehörden (BfDI, BayLDA, LDI), höchstes Abmahnrisiko für Consumer-Produkte.
- Österreich: Enger an EU-Standards, Aufsicht ist weniger proaktiv als DE, Datenschutzbehörde Österreich ist pragmatisch aber streng in Enforcement.
Wer in allen drei Märkten aktiv ist, baut sinnvollerweise ein Maximum-Compliance-Regime, das alle Anforderungen gleichzeitig abdeckt. Kleinere Unternehmen können mit Swiss-First oder Germany-First starten und dann regional ausrollen.
Nächste Schritte und konkrete Empfehlungen
Wer mit Datenpannen-Meldeprozess nach Artikel 33 DSGVO beginnen will, hat einen klaren nächsten Schritt: eine strukturierte Gap-Analyse zwischen Ist- und Soll-Zustand. Typischer Aufwand: 2-4 Wochen bei einem Team von 2-3 Personen, inklusive Stakeholder-Interviews und Dokumenten-Review.
Drei konkrete Hebel für die kommenden 30 Tage:
1. Inventar erstellen: Welche Systeme, Prozesse, Datenflüsse sind im Scope? Wer ist verantwortlich? Wo liegen die grössten Unsicherheiten?
2. Policy-Framework skizzieren: Welche Policies existieren schon, welche fehlen? Nicht sofort ausformulieren — erst die Topologie.
3. Kritischen Pfad identifizieren: Welche drei Schritte reduzieren am meisten Risiko und können in den nächsten 60 Tagen umgesetzt werden?
Innopulse Consulting unterstützt DACH-Unternehmen bei genau diesen Themen — von Gap-Analyse über Policy-Entwicklung bis zur technischen Implementierung. Wer eine zweite Meinung oder Implementation-Support braucht, kann uns unter info@innopulse.io erreichen oder direkt einen Termin anfragen. Die ersten 30 Minuten sind kostenlos — danach arbeiten wir auf klaren, messbaren Deliverables.