Eine Cyber-Versicherung abzuschließen ist einfach – aber sie im Schadensfall tatsächlich ausgezahlt zu bekommen, ist 2026 deutlich schwieriger geworden. Versicherer lehnen rund 41 % aller Erstanträge von KMU ab, und selbst bestehende Policen schützen nicht, wenn die im Risikofragebogen bestätigten Mindeststandards real fehlen. Diese Anleitung zeigt dir, welche fünf Pflicht-Controls Versicherer heute verbindlich fordern, welche Nachweis-Dokumente du benötigst und wie du durch nachgewiesene Sicherheitsreife die Prämie um 20–60 % senken kannst.

Voraussetzungen

Laufende Cyber-Versicherungspolice oder aktuelles Erneuerungsangebot mit Risikofragebogen
Vollständiges Asset-Inventar aller Endpoints (Laptops, Server, IoT, BYOD)
MFA-Coverage-Report als CSV oder PDF mit Abdeckungsprozentsatz je Benutzergruppe
Aktuelle EDR-Deployment-Übersicht (Export aus EDR-Konsole mit Gerätezahl)
Backup-Konfigurationsdokumentation inkl. Immutability-Einstellung und Retention-Perioden
Letztes Restore-Test-Protokoll (Datum, Ergebnis, Unterzeichner, RPO/RTO-Werte)
Patch-Management-SLA-Richtlinie (schriftliches Dokument mit definierten Fristen je CVSS-Schwere)
Patch-Compliance-Export der letzten 3–6 Monate aus WSUS oder RMM als Audit-Log
Schriftlicher Incident-Response-Plan (aktuell, mit Versionsnummer und Datum)
Tabletop-Übungsprotokoll des letzten Jahres (Datum, Teilnehmer inkl. Geschäftsführerebene)
DMARC/SPF/DKIM-Konfigurationsnachweise (DNS-Screenshots oder DNS-Report)

Schritt 1: Die Obliegenheitsverletzungsklausel verstehen

Bevor du die Checkliste abarbeitest, musst du den entscheidenden Vertragsmechanismus kennen. Praktisch jede deutsche Cyber-Police enthält seit 2024/2025 eine Klausel sinngemäß dieses Inhalts:

„Der Versicherungsschutz entfällt, soweit die im Risiko-Fragebogen zugesicherten technischen und organisatorischen Maßnahmen zum Zeitpunkt des Versicherungsfalls nicht in zugesicherter Weise umgesetzt waren."

Das bedeutet: Wenn du im Fragebogen „100 % MFA implementiert" angekreuzt hast, der Angriff aber über ein Konto ohne aktive MFA erfolgte, kann der Versicherer die gesamte Leistung verweigern – unabhängig davon, wie hoch dein Schaden ist. Die Lösung ist nicht, den Fragebogen vorsichtiger auszufüllen, sondern die Controls tatsächlich vollständig umzusetzen und deren Umsetzung nachweisbar zu dokumentieren.

Schritt 2: Die 5-Punkte-Pflicht-Checkliste umsetzen und dokumentieren

Die folgende Tabelle fasst zusammen, was Versicherer 2026 konkret fordern, welchen Abdeckungsgrad sie verlangen und welches Dokument du als Nachweis bereithalten musst:

Control	Mindestanforderung 2026	Nachweis-Dokument	Versicherer-Quote
MFA (erzwungen)	100 % Pflicht-MFA auf E-Mail, VPN, RDP, Cloud, Admin-Konten – kein optionaler Bypass	MFA-Coverage-Report (CSV/PDF) mit Abdeckungsprozentsatz	95–96 %
EDR/XDR	Alle Endpoints inkl. Server und Domaincontroller – kein einziges ungeschütztes Gerät	EDR-Konsolen-Export mit Gerätezahl und Installationsstatus	88–89 %
Immutable Backups	3-2-1-1-0-Regel: 3 Kopien, 2 Medien, 1 Off-Site, 1 unveränderbar (WORM), 0 Fehler beim letzten Restore-Test	Restore-Test-Protokoll (Datum, RPO/RTO, Unterzeichner)	~90 %
Incident-Response-Plan	Schriftlich, mit Rollen, Eskalationspfaden, Playbooks – jährlich per Tabletop-Übung mit GF-Beteiligung getestet	IR-Plan (versioniert) + Tabletop-Protokoll mit Datum und Teilnehmerliste	~85 %
Patch-Management	Kritisch (CVSS ≥ 9.0): 72 h SLA; Hoch (CVSS 7–8.9): 14–30 Tage – belegbar per Audit-Log	WSUS/RMM-Patch-Compliance-Export der letzten 3–6 Monate	~80 %

Control 1: MFA erzwungen – nicht nur verfügbar

Der häufigste Fehler ist der Unterschied zwischen „MFA vorhanden" und „MFA erzwungen". Versicherer meinen Conditional-Access-Pflicht ohne Bypass. In Microsoft Entra ID (Azure AD) bedeutet das: Conditional-Access-Policies, die MFA für alle Nutzer und alle Anwendungen durchsetzen – ohne Named-Location-Ausnahmen für das Büronetz und ohne Legacy-Authentication-Ausnahmen.

Den Nachweis erzeugst du per PowerShell-Report. Richte dazu zuerst die Verbindung zu Microsoft Graph ein und exportiere den MFA-Status aller Benutzer:

# MFA-Coverage-Report aus Azure AD / Entra ID (PowerShell)
# Voraussetzung: Microsoft.Graph PowerShell-Modul installiert
Connect-MgGraph -Scopes 'UserAuthenticationMethod.Read.All','User.Read.All'

$users = Get-MgUser -All
$mfaEnabled = foreach ($u in $users) {
    $methods = Get-MgUserAuthenticationMethod -UserId $u.Id
    [PSCustomObject]@{
        UPN        = $u.UserPrincipalName
        MFAMethods = ($methods.AdditionalProperties['@odata.type'] -join ', ')
        MFAEnabled = ($methods.Count -gt 1)
    }
}
$mfaEnabled | Export-Csv -Path 'MFA_Coverage_Report.csv' -NoTypeInformation
# Ergebnis: Nachweis-CSV mit MFA-Status pro Benutzer fuer den Versicherer

Das erzeugte CSV ist dein Versicherungsnachweis. Stelle sicher, dass in der Spalte MFAEnabled für alle aktiven Benutzerkonten „True" steht – Ausnahmen müssen einzeln schriftlich begründet und mit Kompensationsmaßnahmen dokumentiert werden. Weiterführende Details zur Einrichtung findest du in der Anleitung MFA und Conditional Access in Entra ID einrichten.

Control 2: EDR auf allen Endpoints – Server nicht vergessen

Viele KMU installieren EDR auf Workstations, übersehen aber Dateiserver und Domaincontroller. Genau diese sind der häufigste Angriffspunkt und gleichzeitig Ablehnungsgrund Nummer 1 nach fehlender MFA. Traditioneller Antivirus mit Signaturen wird von Versicherern explizit nicht als EDR-Ersatz akzeptiert – gefordert ist verhaltensbasierte Erkennung mit Telemetrie und Incident-Response-Funktionen (z. B. Microsoft Defender for Endpoint Plan 2, CrowdStrike Falcon, SentinelOne Singularity).

Als Nachweis exportierst du aus deiner EDR-Konsole eine Geräteliste mit Installationsstatus und vergleichst sie mit deinem Asset-Inventar. Jedes Gerät ohne EDR-Abdeckung muss entweder nachgerüstet oder mit schriftlicher Ausnahmedokumentation und Kompensationsmaßnahmen (Netzwerksegmentierung, erhöhtes Monitoring) versehen werden – insbesondere Legacy-Systeme wie Windows Server 2012, die kein modernes EDR unterstützen.

Control 3: Immutable Backups nach 3-2-1-1-0 mit dokumentiertem Restore-Test

68 % der KMU testen ihre Backups nie – das ist Ablehnungsgrund Nummer 2 nach fehlender MFA. Versicherer verlangen nicht nur die Existenz von Backups, sondern ein datiertes Restore-Test-Protokoll. Für die Immutability gibt es zwei verbreitete Ansätze:

Option A: Veeam Hardened Repository (lokaler Linux-Server)

# Veeam Immutability aktivieren (Hardened Linux Repository)
# In Veeam Backup & Replication GUI:
# Backup Infrastructure > Backup Repositories > Add Repository
# Typ: Direct attached storage > Linux
# Schritt 'Repository' > Haken setzen:
#   'Make recent backups immutable for [X] days'
# Empfehlung: X = 30 Tage (mindestens 14 Tage fuer Ransomware-Erkennungsfenster)
#
# Voraussetzungen:
# - Linux-Server mit XFS-Dateisystem
# - Dedizierter non-root-Serviceaccount fuer Veeam
# - Kein SSH Root-Login:
#   PermitRootLogin no  (in /etc/ssh/sshd_config)
#   systemctl restart sshd

Option B: AWS S3 mit Object Lock (Cloud-Backup-Ziel)

# S3 Object Lock fuer immutable Backup-Ziel (AWS CLI)
aws s3api create-bucket \
  --bucket mein-backup-bucket \
  --region eu-central-1 \
  --create-bucket-configuration LocationConstraint=eu-central-1

aws s3api put-object-lock-configuration \
  --bucket mein-backup-bucket \
  --object-lock-configuration \
  'ObjectLockEnabled=Enabled,Rule={DefaultRetention={Mode=COMPLIANCE,Days=30}}'

# Mode=COMPLIANCE: Niemand (auch nicht root/AWS-Admin) kann Objekte vor Ablauf loeschen
# Nachweis der Konfiguration:
aws s3api get-object-lock-configuration --bucket mein-backup-bucket

Wichtig: Setze die Immutability-Periode auf mindestens 30 Tage. Eine Konfiguration auf 7 Tage ist unzureichend – Ransomware-Verschlüsselungen werden häufig erst nach 14–21 Tagen bemerkt, und Versicherer erkennen kürzere Retentions als unzureichend an.

Den Restore-Test dokumentierst du mit einem strukturierten Protokoll:

# Backup Restore-Test dokumentieren (PowerShell-Protokoll-Template)
$TestDate = Get-Date -Format 'yyyy-MM-dd HH:mm'
$Result = @{
    TestDate           = $TestDate
    BackupSet          = 'Veeam_Job_FileServer_2026-06-01'
    RestoreTarget      = 'RESTORETEST-VM'
    TestedBy           = 'Max Mustermann'
    RPO_Achieved       = '4h'
    RTO_Achieved       = '2h30m'
    DataIntegrityCheck = 'PASS'
    VerifiedBy         = 'IT-Leiter'
}
$Result | ConvertTo-Json | Out-File "BackupRestoreTest_$($TestDate.Replace(':','-')).json"
# Dieses JSON-Protokoll ist der Versicherungsnachweis fuer getestete Backups

Control 4: Incident-Response-Plan – jährlich getestet, GF-Beteiligung nachweisbar

Ein drei Jahre alter IR-Plan ohne Tabletop-Protokoll gilt als nicht erfüllt. Versicherer fragen explizit nach dem Datum der letzten Übung und der Teilnehmerliste – fehlende Geschäftsführerbeteiligung kann zur eingeschränkten Police führen. Dein IR-Plan muss folgende Kapitel enthalten:

# Incident Response Plan - Pflicht-Kapitel (Struktur-Template)
# Dokument: IR-Plan_v[VERSION]_[DATUM].docx

# 1. Scope und Geltungsbereich
# 2. Rollen & Verantwortlichkeiten
#    (Incident Commander, Legal, PR, IT-Lead)
# 3. Klassifizierung:
#    P1 (kritisch/Ransomware) | P2 (hoch) | P3 (mittel)
# 4. Eskalationspfade & Kontaktliste
#    (intern + extern: Versicherer-Hotline, Forensiker, BSI CERT-Bund)
# 5. Containment-Playbooks
#    (Ransomware, BEC/CEO-Fraud, Datenleck)
# 6. Evidence-Preservation-Checklist
# 7. Kommunikationsplan (intern/extern/Behoerden)
# 8. Versicherungsbenachrichtigungs-SLA:
#    Meldung an Versicherer innerhalb 24-72h nach Bekanntwerden (Policenbedingung!)
# 9. Tabletop-Uebungs-Protokoll
#    (Datum, Teilnehmer mit Funktion, identifizierte Luecken, beschlossene Massnahmen)

Ein Ransomware-Notfallplan mit konkreten Sofortmaßnahmen findest du in der Anleitung Ransomware-Notfallplan: Die ersten 60 Minuten.

Control 5: Patch-Management mit belegtem 72-Stunden-SLA

Das Unternehmen patcht faktisch schnell – hat aber keine Audit-Logs. Im Schadensfall lässt sich dann nicht belegen, dass kritische Patches (CVSS ≥ 9.0) innerhalb von 72 Stunden eingespielt wurden. Ohne WSUS/RMM-Export gibt es keinen Nachweis.

# WSUS Patch-Compliance-Report (PowerShell) - Nachweis fuer 72h-SLA
[reflection.assembly]::LoadWithPartialName('Microsoft.UpdateServices.Administration') | Out-Null
$wsus = [Microsoft.UpdateServices.Administration.AdminProxy]::GetUpdateServer(
    'WSUSSERVER', $false, 8530)
$scope = New-Object Microsoft.UpdateServices.Administration.UpdateScope
$scope.Classifications = $wsus.GetUpdateClassifications() |
    Where-Object { $_.Title -eq 'Security Updates' }
$updates = $wsus.GetUpdates($scope) |
    Where-Object { $_.IsApproved -and !$_.IsSuperseded }
$report = $updates | Select-Object Title, ArrivalDate,
    @{N='DaysToApproval'; E={ ($_.ArrivalDate - $_.CreationDate).Days }}
$report | Export-Csv 'PatchCompliance_SLA_Report.csv' -NoTypeInformation
# Spalte DaysToApproval belegt Einhaltung des 72h-SLA

Alternativ liefern RMM-Plattformen wie NinjaOne ein Patch-Compliance-Dashboard mit CSV-Export, das direkt als Versicherungsnachweis dient. Details zur automatischen Update-Verwaltung: Windows Updates mit WSUS und Update for Business verwalten.

Schritt 3: E-Mail-Sicherheit und Netzwerksegmentierung prüfen

DMARC/SPF/DKIM und Netzwerksegmentierung gehören zum Standardfragebogen und können zwar selten allein zur Ablehnung führen, aber Risikoaufschläge von 10–20 % verursachen. Überprüfe deine DNS-Einträge:

# DMARC/SPF/DKIM pruefen (Windows PowerShell)
# SPF-Eintrag:
nslookup -type=TXT example.com | Select-String 'v=spf1'
# DMARC-Eintrag:
nslookup -type=TXT _dmarc.example.com
# Ziel: v=DMARC1; p=reject; rua=mailto:dmarc@example.com
# p=reject ist die staerkste Stufe, von Versicherern bevorzugt
# DKIM-Selektor:
nslookup -type=TXT selector1._domainkey.example.com

Zur Netzwerksegmentierung: IT und OT müssen getrennt sein, Admin-VLANs müssen isoliert betrieben werden. Weitere Details zur VLAN-Konfiguration findest du in VLANs verstehen und am Managed Switch einrichten.

Schritt 4: Prämienoptimierung durch nachgewiesene Controls

Gute Controls zahlen sich direkt in der Prämie aus. Die folgende Tabelle zeigt die Prämien-Bandbreiten 2026 und die realisierbaren Reduktionen:

Unternehmensgröße	Standardprämie	Mit allen 5 Controls	Mit ISO 27001
Klein (5–50 MA)	500–5.000 €/Jahr	−20–50 %	weitere −15–25 %
Mittel (50–200 MA, 10–50 Mio. € Umsatz)	5.000–25.000 €/Jahr	−20–50 %	weitere −15–25 %
Mittelstand (>200 MA)	bis 100.000 €/Jahr	−20–50 %	weitere −15–25 %

Maßnahme / Nachweis	Prämienreduktion
Alle 5 Pflicht-Controls dokumentiert nachgewiesen	20–50 % Gesamteinsparung
ISO 27001-Zertifizierung	15–25 % Rabatt
SIEM mit 12 Monaten Log-Retention (append-only)	10–15 %
Verifizierte MFA-Abdeckung (Coverage-Report)	weitere 5–10 %
Fehlende MFA oder EDR	+25–50 % Aufschlag oder Ablehnung

Hinweis zu SIEM: Ab mittlerer Unternehmensgröße stufen führende Versicherer ein SIEM mit mindestens 12 Monaten Log-Retention in unveränderungssicherer Form (append-only) als Pflichtkomponente ein. Open-Source-Optionen wie Wazuh oder Microsoft Sentinel in Azure erfüllen diese Anforderung.

Schritt 5: DSGVO-TOM-Dokumentation vs. Versicherungsnachweise trennen

Ein häufiges Missverständnis: Die vorhandene DSGVO-TOM-Dokumentation wird dem Versicherer als Nachweis eingereicht – und abgelehnt. Der Grund liegt in einem grundlegenden Unterschied:

Aspekt	DSGVO TOM-Dokumentation	Cyber-Versicherungs-Nachweis
Sprache	Qualitativ: „angemessene Verschlüsselung", „regelmäßige Backups"	Quantitativ: „100 % MFA-Coverage", „Restore-Test am 2026-05-15, Ergebnis: PASS"
Schwellenwerte	Keine definierten Prozentwerte oder Fristen	Konkrete Werte: 100 % MFA, 72 h Patch-SLA, ≥30 Tage Immutability
Belege	Beschreibender Text, ggf. Richtlinien	Technische Exporte: CSV-Reports, JSON-Protokolle, Dashboard-Screenshots mit Datum
Aktualisierung	Jährlich oder bei Änderungen	Kontinuierlich: Patch-Logs laufend, Restore-Test mindestens jährlich

Du benötigst zwei getrennte Dokumentations-Sets: das TOM-Dokument für den Datenschutzbeauftragten und die technischen Nachweis-Exporte für den Versicherer. Eine Übersicht zur DSGVO-TOM-Dokumentation findest du in DSGVO TOMs und Auftragsverarbeitung in der Praxis.

Troubleshooting / Typische Fehler

MFA „verfügbar" statt „erzwungen": Im Fragebogen wird „MFA implementiert" bejaht, aber Nutzer können MFA abschalten oder Legacy-Auth-Protokolle umgehen. Fix: Conditional-Access-Policy ohne Named-Location-Ausnahmen und Legacy-Authentication blockieren (Security Defaults oder eigene Policies in Entra ID).
Backup vorhanden, aber nie getestet: Das Restore-Test-Protokoll fehlt oder ist veraltet. Fix: Vierteljährlichen Restore-Test als Kalendertermin einplanen, Protokoll mit JSON-Template (siehe Schritt 3) automatisiert erstellen und datiert ablegen.
EDR nur auf Workstations, nicht auf Servern: Dateiserver und Domaincontroller ohne EDR sind der häufigste Ablehnungsgrund. Fix: Asset-Inventar mit EDR-Konsole abgleichen, alle Server nachrüsten oder Legacy-Systeme mit schriftlicher Ausnahmedokumentation und Kompensationsmaßnahmen versehen.
Patch-SLA kommuniziert, aber nicht dokumentiert: Ohne WSUS- oder RMM-Export kein Nachweis für die 72-Stunden-Einhaltung. Fix: Patch-Compliance-Report aus WSUS (siehe Schritt 5) monatlich exportieren und archivieren.
Immutability-Retention zu kurz konfiguriert: Veeam oder S3 Object Lock auf 7 Tage gesetzt. Ransomware wird oft erst nach 14–21 Tagen bemerkt. Fix: Retention auf mindestens 30 Tage erhöhen; Konfigurationsnachweis per aws s3api get-object-lock-configuration exportieren.
Versicherungsfall nicht rechtzeitig gemeldet: Policenbedingungen schreiben Meldung an den Versicherer typischerweise innerhalb von 24–72 Stunden nach Bekanntwerden vor. Spätmeldung führt zu Leistungsminderung. Fix: Versicherer-Hotline-Nummer im IR-Plan unter Kapitel 4 und 8 hinterlegen, Meldepflicht in Playbooks integrieren.
Third-Party-Risiko nicht dokumentiert: Versicherer fragen 2026 nach TPRM für die Top-10-kritischen Lieferanten. Fix: Vendor-Assessment-Prozess mit einfachem Fragebogen für kritische Dienstleister dokumentieren und im Risikofragebogen belegen können.

Häufige Fragen

Zahlt die Cyber-Police auch, wenn MFA technisch vorhanden, aber nicht für alle Nutzer erzwungen war?

Nein. Die Standard-Vertragsklausel 2026 schließt Leistungen aus, wenn der Schadensfall über ein Konto ohne aktive MFA eintrat und im Fragebogen „100 % MFA" bestätigt wurde. Versicherer prüfen nach dem Schadensfall, ob der Angriffs-Account MFA-gesichert war. Selbst eine 98 %-Abdeckung kann zur Obliegenheitsverletzung führen, wenn genau das ungeschützte Konto betroffen war.

Reicht ein klassischer Antivirus als EDR-Ersatz aus?

Nein. Versicherer unterscheiden seit 2025 explizit zwischen traditionellem Antivirus (signaturbasiert) und EDR/XDR mit verhaltensbasierter Erkennung, Telemetrie und Incident-Response-Funktionen. Produkte wie Microsoft Defender for Endpoint Plan 2, CrowdStrike Falcon oder SentinelOne Singularity erfüllen die Anforderung; Windows Defender in der Basisversion ohne Plan 2 in der Regel nicht.

Genügt die DSGVO-TOM-Dokumentation als Versicherungsnachweis?

Nein. TOM-Dokumente beschreiben Maßnahmen qualitativ und genügen dem Datenschutzrecht. Versicherer fordern quantifizierbare Belege: Coverage-Reports mit Prozentwert (MFA), Testprotokolle mit Datum (Backup, IR-Plan) und SLA-Compliance-Exporte (Patch-Management). Du benötigst getrennte Dokumentations-Sets für beide Anforderungen.

Wie oft muss der Incident-Response-Plan getestet werden?

Mindestens einmal jährlich per Tabletop-Übung mit nachweislicher Geschäftsführungs-Beteiligung. Das Protokoll (Datum, Teilnehmer mit Funktion, identifizierte Lücken, beschlossene Maßnahmen) muss auf Anfrage vorgelegt werden können. Ein IR-Plan ohne aktuelles Tabletop-Protokoll gilt als nicht erfüllt – unabhängig davon, wie gut das Dokument inhaltlich ist.

Was ist der Unterschied zwischen immutable und offline Backup – und was verlangt der Versicherer?

Offline-Backup (Air-Gap) ist physisch vom Netz getrennt und nicht erreichbar; immutable Backup (WORM) ist erreichbar, aber nicht veränderbar. Versicherer verlangen 2026 beides: mindestens eine unveränderliche Kopie (S3 Object Lock Compliance Mode oder Veeam Hardened Repository) und eine vollständig isolierte Offline-Kopie – das entspricht der 3-2-1-1-0-Regel. Nur offline genügt nicht mehr.

Wie viel Prämie spare ich durch nachgewiesene Controls?

Unternehmen, die alle fünf Pflicht-Controls dokumentiert nachweisen können, sparen im Vergleich zu Unternehmen mit bloßen Absichtserklärungen 20–50 %. ISO 27001-Zertifizierung bringt 15–25 % Rabatt obendrauf; SIEM weitere 10–15 %; verifizierte MFA-Abdeckung zusätzlich 5–10 %. Fehlende Controls führen umgekehrt zu 25–50 % Aufschlag oder kompletter Ablehnung.

Fazit

Die Cyber-Versicherung hat sich 2026 von einer Absichtserklärung zu einer technischen Compliance-Anforderung gewandelt. Die Police schützt dich nur dann wirklich, wenn du die fünf Pflicht-Controls – erzwungene MFA, EDR auf allen Endpoints, immutable Backups mit Restore-Test, getesteter IR-Plan und dokumentiertes Patch-Management – nicht nur eingerichtet, sondern auch nachweisbar dokumentiert hast. Wer diese Hausaufgaben macht, wird mit deutlich günstigeren Prämien belohnt; wer sie vernachlässigt, riskiert im schlimmsten Fall eine vollständige Leistungsverweigerung. Starte mit dem MFA-Coverage-Report und dem Restore-Test – das sind die beiden häufigsten Ablehnungsgründe und gleichzeitig die am schnellsten zu schließenden Lücken.

Weiterführende Anleitungen und Quellen

Quellen: GDV Muster-Risikofragebogen Cyber-Versicherung (gdv.de); ADVISORI: Cyber Versicherung Anforderungen und Kosten 2026 (advisori.de); CyberDirekt: Was kostet die Cyberversicherung (cyberdirekt.de); Veeam Helpcenter: Enabling Immutability (helpcenter.veeam.com); BASG Blog: Cyber Insurance Requirements 2026 (basg.co).