¶ Kontakt- und Eskalationslisten
Beispielstruktur: Keine realen Namen, Telefonnummern, Zugangsdaten oder Behördenportale sind eingetragen. Operative Listen werden geschützt geführt und als Notfallkopie außerhalb des Wikis verfügbar gehalten.
Funktionsregel: Ein Kontakt gilt erst nach erfolgreichem Test als einsatzbereit. Ein Eintrag ohne Vertretung, Ausfallkanal und letzten Test ist unvollständig.
¶ Dokumenteninformationen
| Feld | Wert |
|---|---|
| Dokumenten-ID | DSGVO-REG-06-02 |
| Dokumentenart | Leere Musterstruktur für Kontakt- und Eskalationslisten |
| Wiki.js-Pfad | /DSGVO/06-Datenschutzverletzungen/Kontakt-und-Eskalationslisten |
| Verantwortlich | festzulegende Incident- und Datenschutzkoordination |
| Fachlich geprüft durch | Datenschutzbeauftragte/r, Informationssicherheit, IT, Recht, Kommunikation und Notfallmanagement |
| Freigabe durch | Geschäftsführung beziehungsweise dokumentierte befugte Leitung |
| Status | Entwurf – reale Kontakte, Bereitschaften, Vertretungen und Tests fehlen |
| Version | 1.0 |
| Stand | 09.08.2026 |
| Gültig ab | Nach vollständiger Besetzung, Kontaktbestätigung, Ausfalltest und Freigabe |
| Nächste Prüfung | Mindestens vierteljährlich sowie sofort nach Rollen- oder Kontaktdatenänderungen |
| Schutzklasse | Vertraulich; veröffentlichte Seite nur leere Struktur |
| DSGVO-Bezug | Artikel 24, 32, 33 und 34 DSGVO |
| Schnittstellen | Meldeweg, Behördenmeldung, Betroffene, ISMS-Kontaktlisten, BCM und Lieferanten |
Rollen, Vertretungen, Befugnisse und getestete Ausfallkanäle sichern die Handlungsfähigkeit auch außerhalb üblicher Arbeitszeiten. Eigene redaktionelle SVG-Grafik. Zum Vergrößern öffnen.
¶ 1. Listenbereiche
| Bereich | Beispiele für Rollen |
|---|---|
| Annahme | Service Desk, Meldestelle, Bereitschaft, Empfang |
| Incident-Team | Incident Lead, IT-Betrieb, Informationssicherheit, Forensik |
| Datenschutz | Datenschutzkoordination, Datenschutzbeauftragte/r, Vertretung |
| Entscheidung | Geschäftsführung, Recht, Kommunikation, Fachverantwortung |
| Extern | Auftragsverarbeiter, Cyberversicherung, Forensik, Rechtsberatung |
| Behörden | zuständige Datenschutzaufsicht, gegebenenfalls federführende Behörde, weitere Regime |
| Betroffenenhilfe | Hotline, Support, Übersetzung und Barrierefreiheit |
¶ 2. Pflichtfelder je Kontakt
| Feld | Mindestinhalt |
|---|---|
| Rolle / Organisation | Funktionsbezeichnung statt nur Personenname |
| Zuständigkeit | Aufgabe, Entscheidung oder Unterstützung |
| Hauptkontakt | freigegebener Kanal und Erreichbarkeitszeit |
| Vertretung | mindestens eine handlungsfähige Alternative |
| Ausfallkontakt | unabhängiger Kanal bei System- oder Netzausfall |
| Befugnis | welche Entscheidung oder Meldung vorgenommen werden darf |
| Schutz / Authentisierung | sichere Nutzung und Identitätsprüfung |
| letzter Test | Datum, Methode, Ergebnis und Abweichung |
| nächster Review | Termin und Owner |
¶ 3. Leere interne Kontaktliste
| Rolle | Zuständigkeit | Hauptkanal | Vertretung | Ausfallkanal | Erreichbarkeit | letzter Test | Review |
|---|---|---|---|---|---|---|---|
| – | – | – | – | – | – | Kein realer Eintrag im Muster-Wiki | – |
¶ 4. Leere externe Kontaktliste
| Organisation / Rolle | Anlass | Portal / Kanal | Referenz / Zugang | Ausfallweg | Freigabe | letzter Test | Review |
|---|---|---|---|---|---|---|---|
| – | – | – | Geschützt, nicht im öffentlichen Wiki | – | – | – | – |
¶ 5. Aufsichtsbehörde bestimmen
Zuständigkeit, Behördenportal, Telefon, E-Mail, Ausfallverfahren, erwartete Pflichtfelder und federführende Behörde werden organisationsbezogen geprüft. Für die meisten Privatunternehmen ist eine Landesbehörde zuständig; besondere Bundes- und Branchenzuständigkeiten sowie grenzüberschreitende Verarbeitung werden separat bewertet.
¶ 6. Eskalationsstufen
| Stufe | Auslöser | Einzubindende Rollen |
|---|---|---|
| 1 – Verdacht | möglicher Personenbezug | Meldestelle, Incident-Triage |
| 2 – bestätigt | Datenschutzverletzung wahrscheinlich | Datenschutz, Incident Lead, Fachowner |
| 3 – Risiko / Frist | Risiko möglich, unklarer Scope oder laufender Angriff | Recht, Leitung, Kommunikation, DSB |
| 4 – hohes Risiko / Krise | viele oder schutzbedürftige Personen, öffentliche Daten, schwere Folgen | Krisenleitung, Aufsicht, Betroffenenhilfe, externe Spezialisten |
¶ 7. Test und Notfallkopie
- vierteljährlicher Stichprobenanruf oder sicherer Nachrichtentest,
- halbjährliche Tabletop-Übung mit Nacht-/Wochenendszenario,
- Test des Behördenportals ohne Übermittlung realer Meldung, soweit möglich,
- Prüfung von Vertretung, Befugnis und Ausfallkanal,
- geschützte, datierte Offline- oder Exportkopie außerhalb des Wikis,
- dokumentierte Korrektur jeder Abweichung.
¶ 8. Kontaktmatrix nach Entscheidungssituation
Eine lange Telefonliste hilft nicht, wenn unklar ist, wer wann handeln darf. Deshalb wird jeder Kontakt einem konkreten Auslöser zugeordnet.
| Entscheidungssituation | Primäre Funktion | Vertretung und Befugnis |
|---|---|---|
| Verdacht entgegennehmen | Service Desk oder Meldestelle | darf Fall-ID vergeben und Incident-Bereitschaft alarmieren |
| Personenbezug bestätigen | Datenschutzkoordination mit Fachbereich | Vertretung kennt VVT, Systeme und Datenflüsse |
| technischen Angriff eindämmen | Incident Lead / Informationssicherheit | darf definierte Systeme isolieren und Beweise sichern |
| Risiko bewerten | Datenschutz, Recht und Incident-Team | Vier-Augen-Prüfung für Artikel 33 und 34 |
| Behörde melden | ausdrücklich befugte Rolle | Portalzugang, Signatur und Ersatzkanal getestet |
| Betroffene benachrichtigen | Leitung, Datenschutz und Kommunikation | darf Text, Zielgruppe, Kanal und Hilfsangebot freigeben |
| Lieferanten steuern | Vertrags- oder Dienstleisterverantwortung | kennt 24/7-Kontakt, Vertrag und Eskalationsrecht |
| Krisenkommunikation | benannte Kommunikationsrolle | stimmt Aussagen mit Fakten- und Rechtsstand ab |
¶ 8.1 Behörden- und Portalzugänge
Die Liste vermerkt nicht nur eine allgemeine Behördenadresse. Sie enthält zuständige Aufsicht, Meldeportal, erlaubte Dateiformate, erforderliche Konten, Authentisierung, Zeichen- oder Größenbegrenzungen und einen Ausfallweg. Zugangsdaten und Wiederherstellungscodes stehen nicht in der öffentlichen Seite oder offenen Tabelle, sondern in einem geschützten Notfallverfahren.
Für grenzüberschreitende Verarbeitung wird die federführende Behörde geprüft. Bei Verantwortlichen ohne Niederlassung in der Union können nach den EDSA-Leitlinien besondere Zuständigkeitsfragen entstehen. Eine Datenschutzaufsicht, Polizei, BSI/NIS2-Stelle, Versicherung und Vertragspartner sind unterschiedliche Empfänger mit unterschiedlichen Schwellen und Inhalten.
¶ 9. Übungsszenarien
¶ 9.1 Nacht- und Wochenendfall
Eine Auftragsverarbeiterin meldet samstags einen möglichen Datenabfluss. Die Übung prüft, ob die Nachricht erkannt, Incident Lead und Datenschutz erreicht, Vertragsinformationen gefunden und erste Fakten gesichert werden. Es wird nicht angenommen, dass die 72-Stunden-Steuerung erst am Montag beginnt.
¶ 9.2 Ausfall des Hauptkanals
E-Mail, Wiki und Identitätsdienst sind nicht verfügbar. Die Beteiligten nutzen die geschützte Offline-Kopie, einen unabhängigen Kanal und vorab vereinbarte Authentisierung. Nach Wiederherstellung werden Entscheidungen und Zeitstempel in die führende Akte übertragen.
¶ 9.3 Rollenwechsel
Eine benannte Person hat das Unternehmen verlassen. Der Test muss zeigen, ob Funktionspostfach, Vertretung und Portalzugang trotzdem funktionieren. Personenbezogene private Telefonnummern werden nur mit geklärter Zulässigkeit und Schutz verwendet.
¶ 10. Qualitäts- und Aktualitätskontrolle
Jede Änderung an Organisation, Anbieter, Behörde, Portal oder Bereitschaft löst eine Aktualisierung aus. Der vierteljährliche Test dokumentiert Kontakt, Reaktionszeit, erreichte Rolle, Befugnis, Abweichung und Korrektur. Ein unbeantworteter Test wird nicht als „wahrscheinlich erreichbar“ geschlossen.
Die Notfallkopie trägt Version, Erstellungsdatum, nächsten Review und verantwortliche Rolle. Alte Kopien werden kontrolliert eingezogen oder eindeutig als ungültig markiert. Kontakte werden datensparsam geführt; für externe Veröffentlichungen werden offizielle Funktionskontakte bevorzugt.
¶ 11. Verknüpfte Seiten
- Meldeweg für Datenschutzverletzungen
- Meldung an die Aufsichtsbehörde
- Benachrichtigung betroffener Personen
- ISMS Kontakt- und Eskalationslisten
- Datenschutzbeauftragte und Kontakte
¶ 12. Offizielle Grundlagen
- DSGVO, insbesondere Artikel 33 und 34 – EUR-Lex
- BfDI-Kontaktfinder und Zuständigkeitshinweise
- EDSA-Verzeichnis der Aufsichtsbehörden
¶ 13. Weiterführende Informationen von SMCT MANAGEMENT
Unterstützung bei Bereitschaften, Eskalationsmatrizen, Notfallkontakten und Übungen
Erstgespräch unter info@smct-management.de vereinbaren
¶ 14. Änderungshistorie
| Version | Datum | Änderung | Erstellt/geändert durch | Freigabe |
|---|---|---|---|---|
| 1.0 | 09.08.2026 | Entscheidungsbezogene Kontaktmatrix, Portalzugänge, Ausfallszenarien und Aktualitätskontrolle ergänzt | Datenschutzkoordination / Musterrolle | Ausstehend |
| 0.1 | 08.08.2026 | Leere Kontakt- und Eskalationsstruktur mit Rollen, Vertretungen, Behördenzuständigkeit, Ausfallkanälen, Tests und Notfallkopie erstellt | Datenschutzkoordination / Musterrolle | Ausstehend |