IT-Planung · Cyberversicherung
Der Antrag für eine Cyberversicherung ist keine allgemeine Selbsteinschätzung zur Qualität der IT. Gefragt werden konkrete Gefahrumstände, Schutzmaßnahmen, Abhängigkeiten und Vorschäden. Eine belastbare Antwort beschreibt deshalb den tatsächlich umgesetzten Zustand zu einem bestimmbaren Zeitpunkt – einschließlich Geräteklassen, Ausnahmen, Verantwortlichkeiten und Nachweisen.
Fragebögen, Annahmerichtlinien und Versicherungsbedingungen unterscheiden sich nach Anbieter, Branche, Umsatz und Risiko. Auch gleich klingende Begriffe können verschieden definiert sein. „MFA vorhanden“ kann beispielsweise nur einzelne Cloudkonten, alle Beschäftigten oder zusätzlich administrative und externe Zugänge meinen. Vor dem Ankreuzen wird daher jede Frage in einen prüfbaren technischen Geltungsbereich übersetzt.
Dieser Leitfaden hilft kleinen Unternehmen, die benötigten Angaben systematisch zusammenzustellen, widersprüchliche Aussagen zu erkennen und die spätere Police mit dem beschriebenen IT-Betrieb abzugleichen. Er ersetzt weder die Beratung zum passenden Versicherungsschutz noch die rechtliche Auslegung eines konkreten Vertrags.
Direkt zu: Vorgehen · Unternehmensprofil · IT-Inventar · Zugänge · Schutzbetrieb · Backups · Nachweise · Angebote vergleichen
1. Erst wird der Ist-Zustand erhoben, danach wird der Fragebogen beantwortet
Eine gewünschte oder bestellte Maßnahme ist noch keine umgesetzte Maßnahme. Antworten werden erst freigegeben, wenn Geltungsbereich und Wirksamkeit geprüft sind.
| Status | Bedeutung | Geeignete Behandlung |
|---|---|---|
| Vollständig umgesetzt | Die Maßnahme gilt im erfragten Umfang und wurde geprüft. | Mit Geltungsbereich, Stichtag und Nachweis beantworten. |
| Teilweise umgesetzt | Einzelne Systeme, Personen oder Standorte sind ausgenommen. | Nicht pauschal bejahen; Ausnahme und Anteil konkret benennen. |
| Geplant | Entscheidung oder Auftrag existiert, technische Wirkung noch nicht. | Als geplant mit realistischem Termin ausweisen, sofern danach gefragt wird. |
| Unbekannt | Die Organisation besitzt keine ausreichende Information. | Technisch prüfen oder beim Versicherer klären, statt zu raten. |
Schritt für Schritt: Den Antragsprozess technisch vorbereiten
- Vollständigen Originalfragebogen, Erläuterungen und alle Anlagen beschaffen.
- Gewünschten Versicherungsumfang, versicherte Unternehmen und Standorte festhalten.
- Eine geschäftlich verantwortliche Person für die endgültigen Antworten benennen.
- Eine technisch kundige Person oder den zuständigen Dienstleister für die Bestandsaufnahme zuordnen.
- Stichtag festlegen, auf den sich Systembestand und Schutzmaßnahmen beziehen.
- Jede Frage wörtlich übernehmen und unbestimmte Begriffe markieren.
- Begriffe anhand der Erläuterung des Versicherers klären; eigene Definitionen nicht stillschweigend unterstellen.
- Erfragten Geltungsbereich notieren: alle Systeme, nur kritische Systeme, alle Benutzer oder nur Fernzugänge.
- Benötigte Datenquelle und zuständige Person je Frage bestimmen.
- Technischen Ist-Zustand prüfen und bekannte Ausnahmen erfassen.
- Antwort, Begründung, Nachweis und Prüfer in einem Arbeitsregister dokumentieren.
- Widersprüche zwischen Fragebogen, Sicherheitsrichtlinie, Vertrag und technischer Konfiguration auflösen.
- Geplante Verbesserungen getrennt vom aktuellen Zustand führen.
- Unklare Fragen schriftlich an Vermittler oder Versicherer geben und die Antwort zur Antragsakte nehmen.
- Endfassung durch Geschäftsleitung, Technik und gegebenenfalls Versicherungsberatung prüfen.
- Eingereichten Fragebogen samt Anlagen, E-Mails und Versionsstand unverändert archivieren.
Eine Ja-Nein-Antwort braucht häufig eine interne Langfassung
Der eingereichte Fragebogen kann nur ein Kästchen vorsehen. Intern wird trotzdem festgehalten: „MFA gilt für alle interaktiven Microsoft-365-Konten, einschließlich Administratoren; zwei technische Dienstkonten ohne interaktive Anmeldung werden über Zertifikat beziehungsweise verwaltete Identität authentisiert; geprüft am [Datum] durch Export [Bezeichnung].“ Diese Langfassung belegt, wie das Unternehmen die Frage verstanden und geprüft hat.
2. Das Unternehmensprofil bestimmt Schadenspotenzial und relevante Zusatzfragen
Umsatz und Beschäftigtenzahl reichen für eine technische Risikobeschreibung nicht aus. Entscheidend sind auch Datenarten, digitale Abhängigkeiten, externe Leistungen und mögliche Schäden bei Dritten.
| Bereich | Konkrete Angaben | Technische Folgefrage |
|---|---|---|
| Rechtsträger | Versicherungsnehmer, Tochterunternehmen, Betriebsstätten und verbundene Einheiten | Nutzen alle Einheiten dieselben Konten, Netze oder Dienstleister? |
| Geschäftstätigkeit | Leistungen, Branchen, Länder, Onlinehandel und fremde IT-Verantwortung | Welche Leistung kann durch einen IT-Ausfall nicht erbracht werden? |
| Finanzdaten | Umsatz, Onlineumsatz, Zahlungsvolumen und maximale Einzelzahlungen | Wie werden Konto- oder Stammdatenänderungen freigegeben? |
| Daten | Personenbezogene, besondere, vertrauliche und geschäftskritische Informationen | Wo liegen sie und wie viele Personen oder Datensätze können betroffen sein? |
| Abhängigkeit | Maximal tolerierbare Unterbrechung je Kernprozess | Welche Systeme und Anbieter bilden die technische Kette? |
| Dienstleistung für Dritte | Hosting, Software, Administration, Datenverarbeitung oder Lieferzusagen | Können Kunden durch einen eigenen IT-Vorfall Vermögensschäden erleiden? |
| Vorschäden | Angriffe, Datenverletzungen, Erpressung, Ausfälle und Versicherungsfälle | Welche Ursache und welche Abhilfemaßnahme sind dokumentiert? |
| Regulierung und Vertrag | Branchenspezifische Pflichten, Kundenauflagen und Sicherheitszusagen | Welche Kontrollen müssen nachweisbar betrieben werden? |
Abhängigkeiten werden als Prozesskette beschrieben. Bei einer Hausverwaltung kann ein Ausfall von Identitätsdienst, E-Mail, Dokumentenablage oder Fachsoftware die Bearbeitung von Schadensmeldungen und Zahlungen unterbrechen. Bei einer Kanzlei stehen Mandatsdaten, Fristen und sichere Kommunikation im Vordergrund. Diese Beschreibung ist genauer als die Aussage, das Unternehmen arbeite „überwiegend in der Cloud“.
3. Ein prüfbares IT-Inventar verhindert unbemerkte Lücken im Geltungsbereich
Schutzmaßnahmen lassen sich nur für bekannte Geräte, Anwendungen, Konten und Dienstleister beantworten. Stückzahlen allein zeigen weder Aktualität noch Zuständigkeit.
| Objektklasse | Mindestens zu erfassen | Geeigneter Nachweis |
|---|---|---|
| Arbeitsplätze | Geräte-ID, Eigentum, Benutzer, Betriebssystem, Supportstatus, Verschlüsselung und Verwaltung | Export aus Geräteverwaltung plus Ausnahmeliste |
| Server und NAS | Funktion, Standort, Betriebssystem, Exposition, Verantwortlicher und Sicherung | Systeminventar und Konfigurationsbericht |
| Mobilgeräte | Firmen- oder Privatgerät, geschäftliche Daten, Verwaltung, Sperre und Löschmöglichkeit | MDM-Export oder dokumentierte BYOD-Abgrenzung |
| Netzkomponenten | Firewall, Router, Switch, WLAN, Firmware, Fernzugriff und Administration | Konfigurationssicherung und Geräteübersicht |
| Cloud und SaaS | Anbieter, Mandant, Zweck, Administratoren, Datenarten, Vertrag und Beendigung | Vertrags- und Administrationsregister |
| Fachanwendungen | Version, Hersteller, Betrieb, Schnittstellen, Datenbank und Support | Anwendungsliste mit Verantwortlichem |
| Identitäten | Benutzer, Administratoren, Dienstkonten, Gäste und externe Partner | Aktueller Konten- und Rollenexport |
| Domains und DNS | Domaininhaber, Registrar, DNS-Provider, Administratoren und Schutz | Registrar- und DNS-Kontoübersicht |
| Datensicherung | Quelle, Ziel, Frequenz, Aufbewahrung, Isolation, Verschlüsselung und letzter Test | Auftrags-, Lauf- und Wiederherstellungsberichte |
Schritt für Schritt: Den erfassten Bestand gegen die Wirklichkeit prüfen
- Inventar aus Geräteverwaltung, Einkauf, Buchhaltung und vorhandenen Dokumentationen zusammenführen.
- Aktive Benutzer, Gäste, Administratoren und Dienstkonten aus den Identitätsdiensten exportieren.
- Firewall, DHCP, DNS und Verwaltungsportale auf weitere aktive Systeme prüfen.
- Cloudabonnements und wiederkehrende Softwarezahlungen aus Vertrags- und Zahlungsdaten ergänzen.
- Beschäftigte nach geschäftlich eingesetzten Spezialanwendungen und privaten Geräten fragen.
- Für jedes gefundene Objekt Eigentümer und technische Verantwortung zuordnen.
- Nicht unterstützte Systeme, unbekannte Geräte und verwaiste Konten in eine Abweichungsliste übernehmen.
- Stichprobe zwischen Inventar und fünf tatsächlich genutzten Arbeitsplätzen durchführen.
- Stückzahlen und Ausnahmen zum festgelegten Stichtag einfrieren.
- Änderungen nach dem Stichtag in einem getrennten Nachtrag dokumentieren.
4. Zugangsschutz wird nach Benutzerart und Zugriffsweg getrennt beantwortet
Die Aussage „Wir verwenden MFA“ bleibt unvollständig, wenn lokale Administratoren, VPN, Fernwartung, Backupkonsole oder Registrar davon ausgenommen sind.
| Zugangsart | Zu prüfen | Typische offene Angabe |
|---|---|---|
| Normale Benutzer | MFA-Methode, Ausnahmen, Altprotokolle und Registrierungsstatus | Wie viele aktive Konten besitzen keinen zweiten Faktor? |
| Administratoren | Persönliche getrennte Konten, starke MFA, Tageskonto und Rollenbegrenzung | Wer besitzt dauerhaft globale oder lokale Vollrechte? |
| Fernzugriff | VPN oder Zero-Trust-Zugang, MFA, Gerätevoraussetzung und Protokollierung | Existiert eine direkt erreichbare Remote-Desktop-Schnittstelle? |
| Fernwartung | Dienstleisterkonten, Freigabe, MFA, Laufzeit und Sitzungsnachweis | Bleibt unbeaufsichtigter Zugriff dauerhaft aktiv? |
| Dienstkonten | Interaktive Anmeldung, Geheimnisrotation, Rechte und Eigentümer | Welche Konten können nicht mit normaler MFA arbeiten und warum? |
| Notfallkonten | Getrennte Sicherung, Alarmierung, Prüfung und Nutzungsprotokoll | Ist der Zugang auch bei Ausfall des normalen Faktors verfügbar? |
| Externe und Gäste | Sponsor, Ablauf, Berechtigungen und regelmäßige Überprüfung | Welche Zugänge bestehen nach Ende der Zusammenarbeit fort? |
| Cloud- und Domainverwaltung | Registrar, DNS, Backup und SaaS-Administration | Welche kritischen Portale liegen außerhalb der zentralen Identität? |
Konkrete Nachweise für die Antwort „MFA ist aktiviert“
- Export aller aktiven interaktiven Konten mit registrierten Authentisierungsmethoden.
- Richtlinie, die MFA tatsächlich erzwingt, einschließlich Zielgruppen und ausgeschlossener Konten.
- Liste administrativer Rollen und zugehöriger persönlicher Administratorkonten.
- Nachweis, dass ältere Authentisierungsverfahren nicht die Richtlinie umgehen.
- Übersicht der Fernzugänge, Fernwartungsportale und externen Verwaltungsoberflächen.
- Dokumentierte technische Begründung für jedes Konto ohne interaktive MFA.
- Prüfdatum, ausführende Person und gespeicherter Export zur Reproduktion.
5. Sicherheitsverfahren müssen im Arbeitsalltag nachweisbar angewendet werden
Eine unterschriebene Richtlinie zeigt eine Vorgabe. Ob sie bei Zahlungen, Stammdatenänderungen, Phishingmeldungen und Personalwechseln tatsächlich funktioniert, ergibt sich erst aus Zuständigkeit und Stichprobe.
| Verfahren | Konkreter Ablauf | Geeigneter Nachweis |
|---|---|---|
| Zahlungsänderung | Neue Bankverbindung über einen bekannten, unabhängigen Kontakt verifizieren und nach festgelegter Wertgrenze mit zweiter Person freigeben. | Freigabeprotokoll und Stichprobe eines abgeschlossenen Vorgangs |
| Phishingmeldung | Beschäftigte nutzen einen bekannten Meldeweg; zuständige Stelle prüft Nachricht, Konto und mögliche weitere Empfänger. | Testmeldung mit dokumentierter Bearbeitung |
| Ein- und Austritt | Personalverantwortung löst standardisierten Auftrag mit Rolle, Termin, Geräten und Freigaben aus. | Abgeschlossene Checkliste und Abgleich mit aktiven Konten |
| Berechtigungsprüfung | Fachverantwortliche bestätigen regelmäßig benötigte Benutzer-, Gast- und Administratorrechte. | Prüfliste mit Entscheidung und ausgeführtem Entzug |
| Sicherheitsunterweisung | Alle relevanten internen und externen Beschäftigten erhalten verständliche Regeln, Meldeweg und praktische Beispiele. | Teilnahmeliste, Inhalt, Termin und nachverfolgte Erkenntnisse |
| Notfallübung | Rollen bearbeiten ein realistisches Szenario einschließlich Ersatzkommunikation, Entscheidung und Wiederanlauf. | Übungsprotokoll mit Maßnahmen, Verantwortlichen und Abnahme |
Bei einer Stichprobe wird kein künstlich perfekter Musterfall ausgewählt. Ein kürzlich eingetretener Beschäftigter, ein beendeter externer Zugang und eine reale Änderung von Zahlungsdaten zeigen, ob Vorgabe und Ausführung übereinstimmen. Abweichungen werden mit Ursache, Risiko, Korrektur und Termin dokumentiert. Erst nach der Umsetzung darf die interne Langfassung den verbesserten Zustand beschreiben.
6. Patchmanagement und Schadsoftware-Schutz werden als Betriebsprozess beschrieben
Ein installierter Agent beweist weder aktuelle Systeme noch eine überwachte Schutzfunktion. Entscheidend sind Abdeckung, Frist, Ausnahmebehandlung und Kontrolle.
| Prüffeld | Belastbare Angabe | Unzureichende Kurzantwort |
|---|---|---|
| Systemklassen | Windows, macOS, Mobilgeräte, Server, Firewall, NAS, Anwendungen und Browser getrennt | „Updates laufen automatisch“ |
| Fristen | Regelzyklus und beschleunigter Weg für aktiv ausgenutzte oder kritische Lücken | „Zeitnah“ ohne Definition |
| Steuerung | Zentrales Werkzeug, Herstellermechanismus oder dokumentierter manueller Ablauf | „Die Benutzer kümmern sich“ |
| Kontrolle | Bericht über Erfolg, ausstehende Geräte und letzte Verbindung | Nur konfigurierte Richtlinie |
| Ausnahmen | Gerät, Grund, Risiko, Ersatzmaßnahme, Verantwortung und Endtermin | Ausnahme außerhalb des Berichts |
| Schadsoftware-Schutz | Produkt beziehungsweise Bordmittel, Echtzeitschutz, Manipulationsschutz, Aktualität und Alarmweg | Produktname ohne Betriebszustand |
| Überwachung | Wer Warnungen erhält, bewertet, eskaliert und außerhalb von Geschäftszeiten behandelt | „EDR vorhanden“ |
| Supportstatus | Keine nicht unterstützten Betriebssysteme oder dokumentierter, befristeter Sonderfall | Unbekannte Versionsstände |
Schritt für Schritt: Patch- und Schutzstatus zum Stichtag belegen
- Inventar nach Gerätetyp und Betriebssystem gruppieren.
- Je Gruppe die tatsächlich aktive Updatequelle und Richtlinie feststellen.
- Aktuellen Compliancebericht mit letzter Kontaktzeit exportieren.
- Fehlende, inaktive und nicht verwaltete Systeme getrennt ausweisen.
- Firmwarestände kritischer Netz- und Speichergeräte gegen den Herstellersupport prüfen.
- Schutzagenten auf Aktivität, Aktualität und zentrale Meldung kontrollieren.
- Testalarm oder vorhandenen realen Alarm bis zum zuständigen Bearbeiter nachvollziehen.
- Ausnahmen mit Ablaufdatum und kompensierender Maßnahme dokumentieren.
- Ergebnis mit dem im Fragebogen verwendeten Begriff und Geltungsbereich vergleichen.
- Nur den belegten Zustand freigeben; laufende Bereinigung als separate Maßnahme erfassen.
7. Eine Datensicherung wird erst durch Umfang, Isolation und Wiederherstellung aussagekräftig
Synchronisation, Papierkorb, Versionierung und Backup können unterschiedliche Fehler abfangen. Für die Risikoprüfung wird benannt, welche produktiven Daten tatsächlich in welcher Sicherung enthalten sind.
| Angabe | Zu dokumentieren | Prüfnachweis |
|---|---|---|
| Quelle | Server, Arbeitsplatz, Microsoft 365, SaaS, Datenbank, Konfiguration oder Mobilgerät | Abgleich mit vollständigem Inventar |
| Umfang | Enthaltene und ausdrücklich nicht enthaltene Daten | Auftragsdefinition und Dateistichprobe |
| Frequenz | Geplanter Lauf und tatsächlich erreichbarer Wiederherstellungspunkt | Laufhistorie |
| Aufbewahrung | Anzahl und Alter der Wiederherstellungspunkte | Bestandsübersicht im Backupziel |
| Trennung | Separates Konto, unveränderbarer Speicher oder physisch getrennte Kopie | Berechtigungs- und Löschtest |
| Verschlüsselung | Transport, Speicher, Schlüsselinhaber und Notfallzugriff | Konfiguration und Schlüsseltest |
| Überwachung | Empfänger von Fehlern, Reaktionszeit und Vertretung | Beispielalarm und geschlossenes Ticket |
| Wiederherstellung | Letzter Test, Umfang, Dauer, Datenstand und Ergebnis | Restoreprotokoll mit fachlicher Prüfung |
Granulare Prüfung einer behaupteten Offline- oder unveränderbaren Kopie
- Die konkrete Kopie und den zugehörigen Sicherungsauftrag benennen.
- Prüfen, ob produktive Administratoren das Sicherungsziel erreichen können.
- Prüfen, ob ein kompromittiertes Quellkonto vorhandene Sicherungen löschen oder verschlüsseln kann.
- Aufbewahrungssperre, Unveränderbarkeit oder physische Trennung technisch nachvollziehen.
- Separaten Administrations- und Wiederherstellungsweg testen.
- Kontrollieren, ob Schlüssel und zweite berechtigte Person verfügbar sind.
- Eine Sicherung innerhalb der behaupteten Schutzschicht auswählen.
- Testwiederherstellung in getrennte Umgebung ausführen.
- Öffnung, Vollständigkeit und fachlich relevanten Datenstand prüfen.
- Datum, Dauer, Ergebnis und festgestellte Lücke protokollieren.
- Erst danach die Formulierung für den Fragebogen festlegen.
8. Externe Erreichbarkeit, Cloudabhängigkeit und Dienstleister werden gemeinsam erfasst
Ein Betrieb ohne eigenen Server kann dennoch von öffentlich erreichbaren Portalen, Fernwartung, Cloudadministration und einzelnen Anbietern stark abhängig sein.
| Bereich | Technische Fragen | Zu dokumentierende Abhängigkeit |
|---|---|---|
| Internetzugang | Firewall, Firmware, Administration, offene Dienste und Ausweichverbindung | Welche Prozesse stehen ohne Verbindung still? |
| Fernzugriff | Protokoll, MFA, zugelassene Geräte, Rechte und Protokollierung | Wer benötigt ihn und wie wird er entzogen? |
| WLAN | Unternehmens-, Gast- und Gerätezugänge, Verschlüsselung und Segmentierung | Welche Systeme sind aus welchem Netz erreichbar? |
| Cloudidentität | Mandant, Administratoren, Wiederherstellung und Notfallkonto | Welche weiteren Dienste hängen an derselben Identität? |
| SaaS | Datenexport, Backup, Administrator, Support und Vertragsende | Kann der Betrieb bei Ausfall oder Kontosperre weiterarbeiten? |
| IT-Dienstleister | Zugänge, Unterauftragnehmer, Reaktionsvereinbarung und Haftungsgrenze | Welche Systeme kann der Dienstleister verändern? |
| Webauftritt und Shop | Hosting, DNS, Deployment, Zahlungsdienst und Kontozugriff | Welche Einnahmen und Kundendaten sind abhängig? |
| Lieferanten | Kritische Anbieter, Alternativen, Sicherheitsmeldungen und Eskalation | Wie lange ist ein Ausfall tolerierbar? |
Eine externe Schwachstellenprüfung kann öffentlich erreichbare Systeme ergänzend erfassen. Sie ersetzt jedoch weder das interne Inventar noch die Prüfung von Identitäten, Cloudkonfiguration und organisatorischen Abläufen. Ein positives Ergebnis gilt außerdem nur für die geprüften Ziele und den damaligen Zeitpunkt.
9. Vorschäden und bekannte Lücken werden mit Ursache und aktuellem Zustand beschrieben
Ein früherer Phishingfall, eine Kontenübernahme oder ein längerer Ausfall wird nicht durch eine bloße Erledigt-Markierung aussagekräftig.
| Feld | Konkreter Inhalt |
|---|---|
| Zeitraum | Erste Beobachtung, Eindämmung und Wiederaufnahme des Betriebs |
| Art | Kontenmissbrauch, Schadsoftware, Datenabfluss, Erpressung, Betrug oder Ausfall |
| Betroffene Werte | Systeme, Konten, Daten, Prozesse und Dritte |
| Schaden | Betriebsunterbrechung, Wiederherstellung, Forderungen, Zahlungen und Beratung |
| Ursache | Bestätigte Ursache und ausdrücklich verbleibende Unsicherheit |
| Maßnahme | Konkrete technische oder organisatorische Änderung |
| Nachweis | Prüfung, dass die Änderung umgesetzt wurde und wirkt |
| Meldung | Versicherer, Behörde, Betroffene oder Strafverfolgung mit Datum |
| Restpunkt | Noch offene Maßnahme, Verantwortung und Termin |
Bekannte Sicherheitslücken, angekündigte Migrationen und auslaufende Systeme gehören ebenfalls in das interne Prüfregister. Ob und in welcher Form sie dem Versicherer anzugeben sind, wird anhand der konkreten schriftlichen Fragen und fachlicher Beratung entschieden. Technische Beteiligte sollten weder relevante Umstände ausblenden noch ungefragt rechtliche Bewertungen abgeben.
10. Das Antwortregister verbindet jede Aussage mit Quelle, Ausnahme und Freigabe
Screenshots allein veralten schnell und zeigen oft nur einen Ausschnitt. Ein Nachweispaket kombiniert maschinenlesbare Exporte, Konfiguration, Verfahrensbeschreibung und Stichprobe.
| Feld | Eintrag |
|---|---|
| Frage-ID | Nummer und unveränderter Wortlaut |
| Interpretation | Verwendete Definition und erfasster Geltungsbereich |
| Antwort | Ja, nein, teilweise, unbekannt oder erläuterter Zahlenwert |
| Ist-Zustand | Technische Langfassung zum Stichtag |
| Ausnahmen | System, Benutzer, Grund, Risiko und geplantes Ende |
| Nachweis | Dateiname, Export, Bericht, Ticket oder Protokoll |
| Quelle | System und Abfrageweg, aus dem die Information stammt |
| Prüfung | Datum, Prüfer und ausgeführte Stichprobe |
| Klärung | Schriftliche Antwort von Vermittler oder Versicherer |
| Freigabe | Geschäftlich verantwortliche Person und Datum |
Schritt für Schritt: Eine einzelne Antwort belastbar freigeben
- Wortlaut und Antwortformat aus dem Originalfragebogen übernehmen.
- Versichererseitige Definition und Erläuterung lesen.
- Erfragte Systeme, Personen und Zeiträume abgrenzen.
- Zuständiges Quellsystem oder Dokument bestimmen.
- Aktuellen Export erzeugen und unverändert speichern.
- Konfiguration gegen den exportierten Wirkungszustand prüfen.
- Ausnahmen und nicht erfasste Objekte ergänzen.
- Eine technische Langfassung in vollständigen Sätzen formulieren.
- Prüfen, ob geplante Maßnahmen versehentlich als bestehend beschrieben sind.
- Widerspruch zu einer anderen Antwort oder Anlage suchen.
- Bei Unklarheit eine schriftliche Rückfrage mit konkretem Beispiel stellen.
- Antwort nach Klärung aktualisieren und Quelle verknüpfen.
- Geschäftliche Freigabe dokumentieren.
- Eingereichte Version schreibgeschützt in die Antragsakte übernehmen.
Nachweise enthalten sensible Informationen. Kontenlisten, Netzpläne, Schwachstellen und Notfallzugänge werden nicht unaufgefordert vollständig versandt. Das Unternehmen klärt Empfänger, Zweck und sicheren Übertragungsweg und liefert nur die konkret benötigten Unterlagen. Die interne Akte kann ausführlicher sein als das eingereichte Paket.
11. Angebote werden anhand konkreter Szenarien und Vertragsgrenzen verglichen
Eine Versicherungssumme allein zeigt nicht, welche Kosten, Schäden und Dienstleistungen in einem konkreten Vorfall tatsächlich erfasst sind.
| Prüffeld | Zu klärende Frage | Praxisbeispiel |
|---|---|---|
| Versicherungsfall | Welches Ereignis löst welche Leistung aus? | Ist ein bloßer Verdacht mit notwendigen Forensikkosten erfasst? |
| Eigenschäden | Welche Wiederherstellungs-, Mehr- und Betriebsunterbrechungskosten gelten? | Werden interne Mehrarbeit und Ersatzbetrieb berücksichtigt? |
| Drittschäden | Welche Ansprüche und Abwehrkosten sind umfasst? | Gilt Lieferverzug nach IT-Ausfall als versichertes Szenario? |
| Betriebsunterbrechung | Wartezeit, Bewertungszeitraum, Berechnung und Sublimit | Ab wann und wie wird entgangener Ertrag bestimmt? |
| Datenwiederherstellung | Welche Daten, Systeme und Ursachen sind erfasst? | Ist die Rekonstruktion von Cloudkonfiguration eingeschlossen? |
| Cyberbetrug | Ist Überweisungs-, Rechnungs- oder Identitätsbetrug enthalten oder separat? | Greift Schutz bei manipulierter Lieferantenbankverbindung? |
| Erpressung | Beratung, Verhandlung, Zahlung, Recht und Sanktionen | Wer entscheidet und welche Zustimmung ist vor Maßnahmen nötig? |
| Assistance | Hotline, Forensik, Recht, Datenschutz, Kommunikation und Dienstleisterbindung | Darf der eigene IT-Dienstleister tätig werden? |
| Cloud und Provider | Ausfall oder Sicherheitsvorfall eines externen Anbieters | Gilt die Unterbrechung eines zentralen SaaS-Dienstes? |
| Ausschlüsse | Bekannte Umstände, Krieg, Infrastruktur, Vertragsstrafe und veraltete Systeme | Welche konkrete Umgebung fällt außerhalb des Schutzes? |
| Obliegenheiten | Technische und organisatorische Pflichten vor und nach dem Fall | Welche Schutzmaßnahme muss während der Laufzeit fortbestehen? |
| Grenzen | Selbstbehalt, Versicherungssumme, Sublimit und Jahreshöchstleistung | Teilen sich Forensik und Betriebsunterbrechung ein Sublimit? |
Schritt für Schritt: Drei realistische Schadenfälle gegen ein Angebot prüfen
- Drei für den Betrieb plausible Szenarien wählen, etwa Kontenübernahme, Ransomware und Ausfall eines Cloudanbieters.
- Je Szenario betroffene Prozesse, Daten, Systeme und erwartete Dauer beschreiben.
- Benötigte Soforthilfe aus Forensik, Recht, Datenschutz und Kommunikation auflisten.
- Interne Mehrarbeit, externe Wiederherstellung und möglichen Ertragsausfall trennen.
- Mögliche Schäden oder Ansprüche von Kunden und Partnern ergänzen.
- Jede Kostenart einer konkreten Vertragsklausel zuordnen.
- Wartezeiten, Selbstbehalte und Sublimits auf das Szenario anwenden.
- Ausschlüsse und Voraussetzungen mit dem tatsächlichen IT-Zustand vergleichen.
- Vorgaben zur Schadenmeldung und vorherigen Zustimmung in den Notfallplan übernehmen.
- Ungeklärte Auslegung als schriftliche Frage an die Versicherungsberatung formulieren.
- Ergebnis je Szenario als gedeckt, begrenzt, ausgeschlossen oder ungeklärt kennzeichnen.
- Angebote erst nach dieser Zuordnung fachlich und wirtschaftlich vergleichen.
12. Nach Vertragsbeginn müssen Schutzmaßnahmen, Änderungen und Meldewege gepflegt werden
Die Antragsakte beschreibt einen Stichtag. Der reale IT-Betrieb verändert sich durch neue Standorte, Cloudsysteme, Fernzugänge, Übernahmen und Dienstleister.
| Änderung | Technisch zu aktualisieren | Vertraglich zu klären |
|---|---|---|
| Neuer Standort oder Rechtsträger | Netz, Geräte, Konten, Sicherung und Zuständigkeit | Mitversicherung und geänderter Risikoumfang |
| Neue Cloud- oder Fachanwendung | Daten, Administratoren, Backup, Abhängigkeit und Notbetrieb | Provider-, Daten- und Betriebsunterbrechungsdeckung |
| Fernzugriff oder externe Administration | MFA, Gerätebindung, Rechte, Protokolle und Entzug | Erfüllung technischer Voraussetzungen |
| Unterstützungsende eines Systems | Risiko, Segmentierung, Ersatzmaßnahme und Ablösung | Auswirkung auf Obliegenheiten oder Ausschlüsse |
| Sicherheitsvorfall | Ursache, Maßnahme, Nachweis und Restpunkt | Meldung, Zustimmung und Schadenunterlagen |
| Wechsel des IT-Dienstleisters | Zugänge, Dokumentation, Schlüssel und Verantwortungen | Assistancebindung und Ansprechpartner |
| Vertragsverlängerung | Neuer Stichtagsbericht und offene Ausnahmen | Geänderte Fragen, Bedingungen, Summen und Sublimits |
Der Notfallplan enthält den konkreten Versicherungsweg
Police, Versicherungsnummer, Notfallkontakt, Meldefristen, erforderliche Erstangaben und Regeln für die Beauftragung externer Spezialisten werden offline verfügbar gehalten. Das Team weiß, wer melden darf und wann vor kostenpflichtiger Forensik, Verhandlung, Wiederherstellung oder öffentlicher Kommunikation eine Zustimmung einzuholen ist. Maßgeblich bleibt immer der konkrete Vertrag.
- Antragsunterlagen, Police, Nachträge und relevante Korrespondenz liegen in einer versionierten Vertragsakte.
- Technische Nachweise werden mindestens bei wesentlichen Änderungen und vor Verlängerung aktualisiert.
- Offene Ausnahmen besitzen Verantwortung, Termin und dokumentierte Ersatzmaßnahme.
- Notfallkontakte werden regelmäßig auf Erreichbarkeit geprüft.
- IT-Dienstleister kennen ihre technische Rolle, aber nicht automatisch die Befugnis zur versicherungsrechtlichen Entscheidung.
- Ein Vorfallprotokoll erfasst Zeitpunkt, Beobachtung, Maßnahmen, Kosten und Freigaben ab der ersten Meldung.
Häufige Fragen zur technischen Vorbereitung einer Cyberversicherung
Kann der IT-Dienstleister den Fragebogen allein ausfüllen?
Er kann technische Zustände erheben und Nachweise liefern. Umsatz, Geschäftstätigkeit, Vorschäden, Risikotoleranz, vertragliche Zusagen und die endgültige Erklärung liegen jedoch beim Unternehmen und seiner Versicherungsberatung. Die Antworten werden gemeinsam abgestimmt und von einer befugten Person freigegeben.
Darf eine bereits beauftragte Maßnahme als vorhanden angegeben werden?
Eine Beauftragung beweist noch keine technische Wirkung. Der aktuelle und der geplante Zustand werden getrennt. Wenn der Versicherer eine zukünftige Umsetzung akzeptiert, werden Umfang, Termin und gegebenenfalls Voraussetzung für den Versicherungsschutz schriftlich festgehalten.
Ist Microsoft 365 automatisch durch Microsoft gesichert?
Der Dienst besitzt Verfügbarkeits-, Aufbewahrungs- und Wiederherstellungsfunktionen, doch deren Umfang hängt von Dienst, Lizenz, Konfiguration und Ereignis ab. Für eine Versicherungsantwort wird konkret geprüft, welche E-Mails, Dateien, Konfigurationen und Aufbewahrungszeiträume benötigt werden und ob eine zusätzliche Sicherung besteht.
Reicht ein aktueller Virenscanner als technischer Basisschutz?
Er ist nur eine Schutzebene. Fragebögen können zusätzlich Aktualisierung, MFA, Fernzugriff, Berechtigungen, Sicherungen, Schulung und Notfallplanung erfassen. Selbst beim Schadsoftware-Schutz zählen Abdeckung, Aktualität, Manipulationsschutz, Alarmierung und Bearbeitung mehr als der Produktname allein.
Wie aktuell sollten technische Nachweise sein?
Sie sollten den angegebenen Stichtag und die tatsächliche Umgebung abbilden. Schnell veränderliche Daten wie Konten, Rollen, Gerätecompliance und Sicherungsläufe werden unmittelbar zur Prüfung exportiert. Richtlinien und Prozessdokumente erhalten zusätzlich Version, Freigabedatum und verantwortliche Person.
Welche Unterlagen gehören in die interne Antragsakte?
Mindestens der eingereichte Fragebogen, Erläuterungen, Angebote, Police, schriftliche Klärungen, Antwortregister, Inventarstichtag, technische Exporte, Ausnahmeliste und Freigaben. Sensible Rohdaten werden geschützt und nur mit dem erforderlichen Empfängerkreis geteilt.
Weiterführende fachliche Grundlagen
Technische Angaben für den Versicherungsantrag belastbar vorbereiten
fra.digital unterstützt kleine Unternehmen in Frankfurt bei IT-Inventar, Konten- und Rollenprüfung, MFA, Patchstatus, Backupnachweisen, Fernzugängen und Notfalldokumentation. Das Ergebnis ist eine nachvollziehbare technische Bestandsaufnahme, die offene Punkte und geplante Maßnahmen klar vom bereits umgesetzten Zustand trennt.
