Wer Nachweise erst im Schadenfall sucht, ist zu spät
Cyberversicherungen prüfen im Schadenfall nicht nur, ob Massnahmen vorhanden waren, sondern ob sie zum Zeitpunkt des Vorfalls dokumentiert und prüfbar waren. „Wir haben MFA aktiviert" reicht selten. Gefragt wird: Für wen, seit wann, mit welcher Methode, wie war der Status am Tag X?
Das ist kein Versicherungs-Trick. Es ist eine Folge davon, dass Cybervorfälle kein theoretisches Risiko mehr sind. Das Bundesamt für Cybersicherheit (BACS) meldete für das erste Halbjahr 2025 einen hohen fünfstelligen Bereich an Cybervorfallmeldungen, davon ein grosser Teil Betrug und Phishing. Das heisst nicht, dass jedes KMU morgen gehackt wird, es heisst, dass Cyberrisiken real und prüfbar behandelt werden müssen.
Was oft falsch läuft
MFA nicht flächendeckend. GL und IT haben MFA, normale Benutzer nicht. Im Schadenfall fragt die Versicherung den Status aller Konten.
Backup ohne Restore-Protokoll. „Wir sichern täglich" ohne dokumentierten letzten Restore ist kaum verwertbar.
Keine Patch-Logs. Updates laufen, aber niemand führt nach, wann welcher Server wirklich gepatcht wurde.
Offboarding lückenhaft. Ehemalige Mitarbeitende haben noch aktive Konten, VPN-Zugänge oder Adminrechte.
Welche Nachweise typischerweise gefragt werden
| Bereich | Nachweis | Format |
|---|---|---|
| Identität | MFA-Status pro Benutzer, Admin-Inventar | Export aus Entra ID / M365 |
| Backup | Backup-Konzept, letzter Restore-Test | Konzept-PDF + Test-Protokoll |
| Patching | Update-Status Server, Endpoints | Bericht aus Endpoint-Manager / RMM |
| Endpoint Security | EDR/AV aktiv, Coverage-Report | Konsole-Export |
| Netzwerk | Firewall-Konfig, Remote-Access-Doku | Konfig-Export, Runbook |
| Mitarbeiter | Onboarding/Offboarding-Prozess | Checklisten + Logs |
| Vorfallmanagement | Incident-Response-Plan | Dokument + Kontaktliste |
Nicht jede Versicherung fragt alles. Aber wer diese Liste vorbereitet hat, ist auch ohne konkreten Vorfall handlungsfähig.
Beispiel aus dem KMU-Alltag
Ein Handelsbetrieb wird über kompromittiertes Mail-Konto angegriffen, der Angreifer fälscht Lieferantenrechnungen. Die Versicherung zahlt, aber nur nach Nachweis, dass MFA für das betroffene Konto am Vorfallszeitpunkt aktiv war, dass Phishing-Schulung dokumentiert war und dass Login-Logs vorliegen. Vorhanden waren MFA und Logs. Die Schulung war einmal vor zwei Jahren erfolgt, ohne Dokumentation. Das verlängerte die Bearbeitung um Wochen.
Konkrete Empfehlung
Bauen Sie eine Evidence-Map: Pro Massnahme eine Quelle, ein Format, ein Verantwortlicher, ein Aktualisierungszyklus.
- MFA-Report monatlich exportieren
- Backup-Konzept als lebendes Dokument
- Restore-Test halbjährlich, mit Protokoll
- Patch-Bericht monatlich oder quartalsweise
- Onboarding/Offboarding mit Checkliste und Logfile
- Admin-Liste mit Owner und Begründung
- Incident-Response-Plan mit Notfallkontakten
Das Ziel ist nicht ISO-27001-Niveau. Das Ziel ist: Im Schadenfall in 24 Stunden vorlegen können, was die Versicherung sehen will.
Wann wir helfen
Wir führen einen Security-Evidence-Check durch: Was ist vorhanden, was fehlt, was ist veraltet, was lässt sich automatisieren. Ergebnis ist eine Evidence-Map mit konkreten Quick Wins. Teil unserer Leistungen Managed Workplace & Microsoft 365 und Hosting & Infrastruktur. Wie ein realer Vorfall aussehen kann, zeigt das Szenario Online-Shop nach Ransomware-Hit.
Häufige Fragen
Was fragt eine Cyberversicherung typischerweise? MFA, Backup, Patching, EDR, Offboarding, Awareness, Incident-Response, in unterschiedlicher Tiefe je nach Police.
Muss jedes KMU alles erfüllen? Nein. Aber je weniger erfüllt ist, desto teurer wird die Police oder desto enger die Deckung.
Was ist ein Restore-Protokoll? Ein Dokument, das festhält, wann was getestet wurde, wie lange es dauerte und welche Daten betroffen waren.
Welche M365-Berichte sind sinnvoll? MFA-Status, Sign-in-Logs, Risiko-Reports, Admin-Aktivitäten, exportierbar aus Entra ID.
Wie oft aktualisieren? Monatlich für laufende Reports, halbjährlich für Konzepte und Restore-Tests.