DSGVO 72h · NIS2 · BaIT · Template
Stand: Geprüft gegen Art. 33 + NIS2-UmsuCGQuelleIncident-Response-Plan-Template
Vollständiger IR-Plan mit Schweregrad-Klassifizierung, Eskalations-Kette, Meldepflichten-Fristen-Tabelle (DSGVO 72 h, NIS2 24 h / 72 h / Monat, BaIT unverzüglich), Forensik, Kommunikation, Lessons-Learned. Markdown-Export.
Frequently Asked Questions
Wann muss ich einen Datenschutz-Vorfall an die Aufsichtsbehörde melden?
Art. 33 DSGVO verpflichtet zur Meldung binnen 72 Stunden ab Kenntnis, wenn ein Risiko für Rechte und Freiheiten betroffener Personen besteht. "Kenntnis" bedeutet: ab dem Moment, in dem klar ist, dass es zu einer Datenschutzverletzung gekommen ist — nicht erst nach abgeschlossener Forensik. Wer die 72 h reißt, muss begründen warum. Kein Risiko = keine Meldung (z. B. korrekt verschlüsselte verlorene Festplatte).
Was ist die NIS2-24h-72h-Monat-Regel?
Für NIS2-pflichtige Einrichtungen (Energie, Transport, Gesundheit, Digitalwirtschaft etc.): 24 h Frühwarnung (was ist passiert?), 72 h Erstmeldung (was wissen wir?), 1 Monat Abschlussbericht (wie haben wir reagiert?). Die Stufen ersetzen einander nicht — alle drei sind pflichtig. Quelle: NIS2-UmsuCG § 32 (vorbehaltlich finaler Verabschiedung).
Wer muss intern alarmiert werden?
Mindestens: IT-Lead (technische Eindämmung), DSB (DSGVO-Relevanz), Geschäftsleitung (rechtliche/wirtschaftliche Auswirkung). Bei Schweregrad "hoch" / "kritisch" zusätzlich: externe Forensik, Presse, ggf. Hausanwalt. Eskalations-Ketten brauchen Stellvertreterregelung und 24/7-Erreichbarkeit für kritische Systeme.
Was ist der Unterschied zwischen Incident und Breach?
Incident = Sicherheitsvorfall (Verdacht oder Bestätigung). Breach (DSGVO Art. 4 Nr. 12) = Verletzung des Schutzes personenbezogener Daten — Unterkategorie von Incident, die DSGVO-Meldepflichten auslöst. Nicht jeder Incident ist Breach: ein abgewehrter Phishing-Angriff ohne Datenabfluss ist kein Breach. Trotzdem als Incident dokumentieren.
Warum brauche ich klare Schweregrade?
Damit das Team in der akuten Situation nicht diskutieren muss, sondern handelt. Klare Schwellwerte (z. B. "mehr als 100 Datensätze betroffen = mindestens hoch") sparen wertvolle Minuten. In der Krise hilft Klarheit mehr als Eleganz.
Was gehört in "Lessons Learned"?
Post-Mortem ohne Schuldzuweisung: was ist passiert, wann, wer hat reagiert, was hat funktioniert, was nicht. Root-Cause-Analyse: technische und prozessuale Ursachen. Maßnahmen mit Verantwortlichen und Fristen. Plan-Update: was im IR-Plan ergänzen, weglassen, klarstellen.
Ersetzt dieses Template einen professionellen IR-Plan?
Es liefert eine solide Basis mit Pflichtangaben für DSGVO/NIS2/BaIT. Für komplexe Umgebungen (mehrere Standorte, internationale Tochter, Hochrisiko-Branchen) empfiehlt sich Begleitung durch IT-Sicherheits-Spezialist:innen und Fachanwält:innen. Wichtig: ein IR-Plan ohne Übung ist unwirksam. Mindestens jährlich Tabletop-Übung durchführen.