TRUST CENTER – UNTERNEHMENSKONTINUITÄT & DISASTER RECOVERY

Onesurance & Notfallwiederherstellung
Zuletzt aktualisiert: Dezember 2024

Unser Engagement

Wir bei Onesurance , dass unsere Kunden aus der Versicherungsbranche für ihre täglichen Abläufe auf die Verfügbarkeit unserer Plattform angewiesen sind. Deshalb haben wir umfassende Pläne und Verfahren, um die Kontinuität unserer Dienste auch bei unerwarteten Ereignissen sicherzustellen. Unser Ansatz kombiniert vorbeugende Maßnahmen, proaktive Planung und getestete Wiederherstellungsverfahren.

Dienstgütevereinbarung (SLA)

Verfügbarkeitsgarantie
• Verfügbarkeit: 99,9 % pro Monat (maximal 43 Minuten Ausfallzeit pro Monat)
• Berechnung: (Gesamtminuten – Ausfallzeit) / Gesamtminuten × 100 %
• Messung: Automatisierte externe Überwachung durch Tools von Drittanbietern
• Berichterstattung: Monatliche SLA-Berichte über das Kundenportal verfügbar
• Servicegutschriften: Bei Nichterfüllung der vertraglich vereinbarten SLA

Ausschlüsse
• Geplante Wartungsarbeiten: Mindestens 7 Tage im Voraus angekündigt
• Höhere Gewalt: Außerhalb unserer angemessenen Kontrolle
• Vom Kunden verursachte Probleme: Konfigurationsfehler, Überlastung durch den Kunden
• Ausfälle von Drittanbieterdiensten: Außerhalb der Azure-Kernservices
• Beta-/Experimental-Funktionen: Ausdrücklich gekennzeichnet

Geplante Wartungs
• Häufigkeit: Maximal 1× pro Monat
• Dauer: Maximal 4 Stunden
• Zeitplan: Außerhalb der Bürozeiten (20:00 – 06:00 Uhr MEZ)
• Benachrichtigung: Mindestens 7 Tage im Voraus, per E-Mail und auf der Statusseite
• Keine Ausfallzeiten, soweit möglich: Verwendung von Blue-Green-Deployments

Support & Reaktionszeiten

P1 – Kritisch (Serviceausfall)
• Erste Reaktion: 15 Minuten
• Updates: Stündlich während des Vorfalls
• Lösungsziel: 4 Stunden
• Eskalation: Automatisch an das Management

P2 – Hoch (erhebliche Beeinträchtigung)
• Erste Reaktion: 1 Stunde
• Aktualisierungen: Alle 4 Stunden
• Lösungsziel: 8 Stunden (Geschäftszeiten)
• Eskalation: Nach 4 Stunden

P3 – Mittel (geringe Auswirkungen)
• Erste Reaktion: 4 Geschäftsstunden
• Updates: Täglich
• Lösungsziel: 2 Werktage
• Eskalation: Bei Verzögerungen

P4 – Niedrig (Frage/Verbesserung)
• Erste Antwort: 1 Werktag
• Updates: Auf Anfrage
• Lösungsziel: 5 Werktage
• Eskalation: Nicht erforderlich

Geschäftskontinuitätsplan (BCP)

Umfang

Der BCP deckt Folgendes ab:
• IT-Infrastruktur und -Dienstleistungen
• Anwendungsverfügbarkeit
• Datenintegrität und -wiederherstellung
• Personalkontinuität
• Abhängigkeiten von Lieferanten
• Kundenkommunikation
• Einhaltung gesetzlicher Vorschriften

Nicht im Umfang enthalten (separate Pläne):
• Wiederherstellung der physischen Büroinfrastruktur (Homeoffice möglich)
• Finanzielle Kontinuität (Verantwortung des CFO)
• Rechtliche Kontinuität (Rechtsabteilung)

Kritische Geschäftsprozesse

Tier 1 – Geschäftskritisch (RTO: 4 Stunden, RPO: 5 Minuten)
• Verfügbarkeit der Kernplattform
• API-Endpunkte
• Datenbankzugriff
• Authentifizierung und Autorisierung
• Verarbeitung durch die Risk Engine
• Kunden-Dashboards

Tier 2 – Wichtig (RTO: 8 Stunden, RPO: 1 Stunde)
• Berichterstellung und Analysen
• Admin-Portale
• Stapelverarbeitung
• E-Mail-Benachrichtigungen
• Integrations-Webhooks

Tier 3 – Normal (RTO: 24 Stunden, RPO: 24 Stunden)
• Dokumentationsportale
• Schulungsmaterialien
• Nicht kritische Hintergrundaufgaben
• Marketing-Website

Business Impact Analysis (BIA)

Durchgeführt: Jährlich und bei wesentlichen Änderungen
Letzte Bewertung: [Datum]

Auswirkungskategorien:
• Finanziell: Umsatzverluste, Vertragsstrafen
• Operativ: Unfähigkeit, Dienstleistungen zu erbringen
• Reputationsbezogen: Kundenvertrauen, Imageschaden
• Regulatorisch: Nichteinhaltung von Vorschriften, Geldstrafen
• Vertraglich: Verstöße gegen SLAs

Akzeptable Ausfallzeiten:
• Tier 1: Maximal 4 Stunden vor erheblichen Auswirkungen
• Tier 2: Maximal 8 Stunden
• Tier 3: Maximal 24 Stunden

Identifizierte Abhängigkeiten:
• Microsoft Azure: Primäre Abhängigkeit
• Internetverbindung: Mehrere ISPs
• Personal: Abhängigkeiten von Schlüsselpersonen gemindert
• Dienste von Drittanbietern: Bewertet und dokumentiert

Strategie zur Notfallwiederherstellung (Disaster Recovery, DR)

Wiederherstellungsziele

RTO (Recovery Time Objective): 4 Stunden
• Definition: Maximal akzeptable Zeit für die Wiederherstellung von Diensten
• Umfang: Tier-1-Dienste (geschäftskritisch)
• Messung: Vom Beginn des Vorfalls bis zur vollständigen Funktionsfähigkeit
• Ziel: 4 Stunden für 99 % der Szenarien

RPO (Recovery Point Objective): 5 Minuten
• Definition: Maximal akzeptabler Datenverlust
• Umfang: Alle Kundendaten
• Messung: Zeitpunkt der letzten erfolgreichen Sicherung
• Implementierung: Kontinuierliche Datenbankreplikation

DR Architektur

Primäre Website
• Region: Azure West-Europe (Amsterdam, NL)
• Verfügbarkeitszonen: 3 Zonen für Redundanz
• Konfiguration: Aktive Multi-Zonen-Bereitstellung

DR-Standort
• Region: Azure North-Europe (Irland)
• Status: Warm Standby (vorab bereitgestellt, nicht aktiv)
• Datenreplikation: Echtzeit für Datenbanken
• Konfigurationssynchronisierung: Automatisiert über IaC

Failover-Ansatz
• Datenbanken: Automatisierte Failover-Gruppen (innerhalb der EU)
• Anwendungen: Manuelles Failover nach Bewertung
• DNS: Automatisiertes Failover über Azure Traffic Manager
• Überwachung: Fortlaufend am DR-Standort

DR-Szenarien

Scenario 1: Availability Zone Failure
• Likelihood: Low (maar voorbereid)
• Detection: Automated health checks
• Response: Automatische failover naar andere zones
• Impact: Geen of minimaal (seconden)
• RTO: <5 minuten
• RPO: 0 (real-time replication)

Szenario 2: Regionaler Ausfall
• Wahrscheinlichkeit: Sehr gering (aber vorbereitet)
• Erkennung: Überwachung, Azure-Status, Warnmeldungen
• Reaktion: Manuelles Failover zur DR-Region nach Bewertung
• Auswirkungen: Moderat (Dienstunterbrechung)
• RTO: 4 Stunden (einschließlich Bewertung und Koordination)
• RPO: 5 Minuten

Szenario 3: Datenbeschädigung/-löschung
• Wahrscheinlichkeit: gering (Zugriffskontrollen, Backups)
• Erkennung: Überwachung, Benutzerberichte, Datenvalidierung
• Reaktion: Point-in-Time-Wiederherstellung aus Backups
• Auswirkungen: variieren je nach betroffenem Umfang
• RTO: 1–4 Stunden (abhängig vom Datenvolumen)
• RPO: 5 Minuten

Szenario 4: Ransomware/Malware
• Wahrscheinlichkeit: gering (Präventionsmaßnahmen)
• Erkennung: Antivirus, Anomalieerkennung, Überwachung
• Reaktion: Isolieren, beseitigen, aus sauberen Backups wiederherstellen
• Auswirkungen: potenziell hoch (bei weit verbreiteter Ausbreitung)
• RTO: 4–8 Stunden (einschließlich Forensik, Verifizierung)
• RPO: 5 Minuten (unveränderliche Backups)

Szenario 5: Major Azure Global Outage
• Wahrscheinlichkeit: Sehr selten (aber nicht auszuschließen)
• Erkennung: Azure-Status-Dashboard, Microsoft-Kommunikation
• Reaktion: Eskalation an Microsoft, Warten auf Lösung
• Auswirkung: Hoch (Failover innerhalb von Azure nicht möglich)
• RTO: Abhängig von der Lösung durch Microsoft
• Notfallplan: Kommunikationsplan, alternative Arbeit

Backup-Strategie

Datenbank-Backups
• Typ: Automatisierte Azure SQL-Datenbank-Backups
• Häufigkeit: Kontinuierlich (Point-in-Time-Wiederherstellung alle 5 Minuten)
• Aufbewahrung:

• Kurzfristig: 35 Tage Point-in-Time-Wiederherstellung

• Langfristig: Wöchentliche Backups für 10 Jahre
  • Speicherung: Georedundant (innerhalb der EU repliziert)
  • Verschlüsselung: AES-256 für alle Backups
  • Tests: Monatliche Wiederherstellungstests

Anwendungs- und Konfigurations-
• Typ: Infrastructure as Code (Terraform)
• Häufigkeit: Bei jeder Änderung (versionskontrolliert)
• Speicherung: Git-Repository mit Verzweigungsstrategie
• Verschlüsselung: Verschlüsselung auf Repository-Ebene
• Tests: Automatisierte Bereitstellungstests in der Staging-Umgebung

Dateispeicherung (Blob Storage)
• Typ: Geo-redundanter Speicher (GRS)
• Häufigkeit: Echtzeit-Replikation
• Versionierung: Aktiviert (30 Tage Versionsverlauf)
• Soft Delete: 30 Tage Aufbewahrungsfrist
• Unveränderlicher Speicher: Für compliancekritische Daten

Protokolle und Auditdaten
• Typ: Azure Log Analytics Langzeitarchivierung
• Häufigkeit: Kontinuierliche Erfassung
• Aufbewahrung: 1 Jahr online, 7 Jahre archiviert
• Speicherung: Unveränderlich, verschlüsselt
• Testen: Vierteljährliche Wiederherstellungsüberprüfung

Backup-Tests
• Häufigkeit: Monatliche automatisierte Wiederherstellungstests
• Umfang: Beispieldatenbanken, aktuelle Backups
• Validierung: Datenintegritätsprüfungen, Vollständigkeit
• Vollständiger DR-Test: Halbjährlich (siehe DR-Tests)
• Dokumentation: Testresultate protokolliert und überprüft

DR-Prüfung

Testhäufigkeit und -arten

Monatlich: Backup-Wiederherstellungstests
• Umfang: Beispielhafte Backup-Wiederherstellungs
• Umgebung: Isolierte Testumgebung
• Validierung: Datenintegrität, Vollständigkeit
• Dauer: 2–4 Stunden
• Bestehenskriterien: Erfolgreiche Wiederherstellung ohne Fehler

Quartalsweise: Failover-Tests
• Umfang: Datenbank-Failover in die DR-Region
• Umgebung: Nicht-Produktionsreplikation
• Validierung: Failover-Erfolg, Datenkonsistenz
• Dauer: 4 Stunden
• Bestehenskriterien: RTO/RPO innerhalb der Zielvorgaben

Halbjährlich: Vollständige DR-Simulation
• Umfang: Vollständiges Plattform-Failover, alle Ebenen
• Umgebung: Kontrollierter Test mit ausgewählten Kunden
• Teams: Alle IR-/DR-Teams, Management
• Dauer: 8 Stunden (ganztägige Übung)
• Validierung:

• Alle Dienste wiederhergestellt

• Datenintegrität bestätigt

• Befolgte Kommunikationsprotokolle

• RTO/RPO-Ziele mit
  • Dokumentation: Umfassende Berichts
  • Verbesserungen: Behandelte Aktionspunkte

Jährlich: Katastrophenszenario-Übung
• Umfang: Realistische, komplexe Katastrophe (Tabletop + technisch)
• Teilnehmer: Gesamtes Unternehmen, wichtige Stakeholder
• Szenarien: Vielfältig (Ransomware, regionaler Ausfall usw.)
• Dauer: Ganztägig
• Ergebnisse:

• Teamvorbereitung bewertet

• Identifizierte Lücken

• Planverbesserungen

• Schulungsbedarf

Testdokumentation
• Testplan: Ziele, Umfang, Erfolgskriterien
• Testdurchführung: Schritt-für-Schritt-Protokoll
• Ergebnisse: Bestehen/Nichtbestehen pro Komponente
• Probleme: Aufgetretene Probleme und Lösungen
• Verbesserungen: Empfehlungen für Planaktualisierungen
• Abnahme: Genehmigung durch das Management

Personalkontinuität

Abhängigkeiten von Schlüsselpersonen
• Identifiziert: Alle kritischen Rollen zugeordnet
• Risikominderung: Cross-Training, Dokumentation
• Backup: Zweitperson pro kritischer Rolle
• Wissenstransfer: Regelmäßige Rotation

On-Call-Rotation
• Coverage: 24/7 für kritische Systeme
• Rotation: Wöchentliche Rotation zwischen Ingenieuren
• Eskalation: Klare Eskalationswege
• Vergütung: Bereitschaftsdienstzulage + Überstunden

Remote-Arbeitsfähigkeit
• Infrastruktur: Cloud-basiert, weltweit zugänglich
• VPN: Verfügbar für sicheren Fernzugriff
• Ausstattung: Laptops werden gestellt, BYOD-Richtlinie
• Tests: Regelmäßige Remote-Arbeitsübungen
• Richtlinie: Homeoffice als Standard für DR

Nachfolgeplanung
• Schlüsselrollen: Identifizierung von Stellvertretern für das Management
• Dokumentation: Dokumentation der Aufgabenbereiche
• Übergänge: Reibungslose Übergabeverfahren
• Befugnisse: Delegierte Entscheidungsfindung in DR

Lieferanten- und Drittanbieter-Kontinuität

Kritische Lieferanten

Microsoft Azure
• Risiko: Primärer Infrastrukturanbieter
• SLA: 99,99 % mit finanziellen Strafen
• DR: Mehrere Regionen, Verfügbarkeitszonen
• Überwachung: Azure-Status-Dashboard
• Eskalation: Premier-Supportvertrag
• Alternative: Nicht durchführbar (vollständige Migration = Monate)
• Risikominderung: Bereitstellung in mehreren Zonen, DR-Region

Bonsai Software (Entwicklungspartner)
• Risiko: Abhängigkeit von Entwicklungskapazitäten
• SLA: Bestmögliche Unterstützung
• DR: Nicht kritisch (interne Tools)
• Risikominderung: Dokumentation von Wissen, Code-Eigentumsrechte
• Alternative: Internes Team kann Wartung übernehmen

Lieferantenbewertung
• Häufigkeit: Jährliche Lieferantenrisikobewertungen
• Kriterien: Finanzielle Stabilität, BC-Pläne, Sicherheit
• Dokumentation: BC-Pläne der Lieferanten in den Akten
• Verträge: BC-Anforderungen in Vereinbarungen
• Überwachung: Laufende Leistungsüberwachung

Kommunikationsplan

Stakeholder-Kommunikation

Internes Team
• Kanal: Microsoft Teams-Kanal
• Häufigkeit: Echtzeit-Updates während DR-Ereignissen
• Inhalt: Status, Maßnahmen, nächste Schritte
• Verantwortung: DR-Koordinator

Management/Führungskräfte
• Kanal: Direktanruf, E-Mail, Teams
• Häufigkeit: Stündlich (P1), alle 4 Stunden (P2)
• Inhalt: Auswirkungen, Fortschritt, erforderliche Entscheidungen
• Verantwortlichkeit: CTO / DR-Manager

Kunden
• Kanal: E-Mail, Statusseite, In-App-Benachrichtigungen
• Häufigkeit: Erste Benachrichtigung, dann stündliche Updates
• Inhalt:

• Was los ist

• Welche Dienste sind betroffen?

• Erwartete Erholungszeit

• Alternativen (falls verfügbar)

• Nächstes Update-Timing
  • Verantwortung: Customer Success + DR Manager

Regulierungsbehörden
• Auslöser: Bedeutende Vorfälle mit Auswirkungen auf die Compliance
• Zeitplan: Gemäß den regulatorischen Anforderungen

• Verstoß gegen die DSGVO: Innerhalb von 72 Stunden

• DORA: Pro Vorfall Klassifizierungs
  • Inhalt: Vorfalldetails, Auswirkungen, Abhilfemaßnahmen
  • Verantwortung: FG / Compliance Officer

Medien/Öffentlichkeit (falls erforderlich)
• Auslöser: Aufsehenerregende Vorfälle, Medienanfragen
• Genehmigung: Führungsteam
• Sprecher: Beauftragter Vertreter
• Botschaft: Im Einklang mit der Kundenkommunikation

Statusseite
• URL: onesurance
• Updates: Echtzeitstatus, Vorfallverlauf
• Abonnements: E-Mail-/SMS-Benachrichtigungen verfügbar
• Transparenz: Öffentliche Sichtbarkeit der Verfügbarkeit

Vorlagen
• Vorab genehmigte Vorlagen für gängige Szenarien
• Tonfall: Professionell, transparent, einfühlsam
• Sprachen: Niederländisch und Englisch
• Überprüfung: Rechtliche Genehmigung für kritische Mitteilungen

Compliance und Regulierung

Regulatorische Anforderungen

DORA (Digital Operational Resilience Act)
• Gilt für: Kunden aus dem Versicherungssektor
• Anforderungen:

• ICT-Risikomanagement-Rahmenwerk

• Meldung von Vorfällen (24 Stunden bei schwerwiegenden Vorfällen)

• Resilienztests (jährlich)

• Risikoüberwachung durch Dritte
  • Compliance: BC/DR-Plan in Übereinstimmung mit DORA
  • Tests: Jährlicher DORA-spezifischer Resilienztest
  • Berichterstattung: Klassifizierung und Meldung von Vorfällen

AVG/GDPR
• Anforderung: Datenverfügbarkeit und -integrität
• Backups: Verschlüsselt, getestet, aufbewahrungskonform
• Datenverletzung: Benachrichtigungsverfahren (siehe Vorlage 06)
• Folgenabschätzungen: DPIA für BC/DR-Prozesse

Vertragliche Verpflichtungen
• SLA-Verpflichtungen: 99,9 % Verfügbarkeit
• Datenaufbewahrung: Gemäß den Vertragsbedingungen
• Benachrichtigung: Benachrichtigung des Kunden bei Vorfällen
• Tests: Recht auf Beobachtung von DR-Tests

Dokumentation & Aufzeichnungen

BC/DR-Dokumentation
• Business Continuity Plan: Dieses Dokument
• Disaster Recovery Procedures: Technische Runbooks
• Testergebnisse: Alle Tests protokolliert
• Vorfallberichte: Analysen nach Vorfällen
• Risikobewertungen: Jährliche BIA
• Lieferantenbewertungen: Bewertungen durch Dritte

Aufbewahrungsfristen
• Pläne: Aktuelle Version + 3 Jahre Historie
• Tests: 7 Jahre
• Vorfälle: 7 Jahre
• Bewertungen: 7 Jahre
• Verfügbarkeit: Für Auditoren und Aufsichtsbehörden auf Anfrage

Plan Wartung

Update-Auslöser
• Jährlich: Geplante umfassende Überprüfung
• Wesentliche Änderungen: Neue Dienstleistungen, Infrastruktur, Personal
• Nach einem Vorfall: Nach größeren Vorfällen
• Nach einem Test: Nach DR-Tests mit identifizierten Lücken
• Regulatorische Änderungen: Neue Compliance-Anforderungen
• Änderungen bei Lieferanten: Neue/geänderte Abhängigkeiten

Überprüfungsprozess

1. Entwürfe für Aktualisierungen (DR Manager)

2. Technische Überprüfung (Ingenieurteam)

3. Compliance-Prüfung (FG/Legal)

4. Genehmigung durch die Geschäftsleitung

5. Kommunikation mit Stakeholdern

6. Schulung zu Änderungen

7. Versionskontrolle und Verteilung

Governance-
• Eigentümer: CTO
• Genehmiger: Führungsteam
• Überprüfungszyklus: Jährlich
• Nächste Überprüfung: [Datum]

Kontinuierliche Verbesserung

Leistungskennzahlen
• Tatsächliche RTO/RPO: Gemessen bei Vorfällen und Tests
• Test-Erfolgsquote: % bestandene DR-Tests
• Backup-Erfolgsquote: % erfolgreiche Backups
• Wiederherstellungs-Erfolgsquote: % erfolgreiche Wiederherstellungen
• Vorfallhäufigkeit: Anzahl und Schweregrad
• Compliance: % konform mit Anforderungen

Berichterstattung
• Monatlich: Backup- und Verfügbarkeitsberichte
• Vierteljährlich: BC/DR-Metriken-Dashboard
• Halbjährlich: Vollständige Überprüfung des BC/DR-Programms
• Jährlich: Executive Report für den Vorstand

Verbesserungsquellen
• Nachbesprechungen nach Vorfällen: Gewonnene Erkenntnisse
• Testergebnisse: Identifizierte Lücken
• Branchenweit bewährte Verfahren: Benchmarking
• Rückmeldungen von Aufsichtsbehörden: Feststellungen von Wirtschaftsprüfern
• Technologische Fortschritte: Neue Funktionen

Verantwortlichkeiten des Kunden

Modell der geteilten Verantwortung
• Onesurance : Plattformverfügbarkeit, Datensicherungen
• Der Kunde ist verantwortlich für:

• Benutzerzugriffsverwaltung

• Datengenauigkeit und -qualität

• Export und Archivierung eigener Berichte (falls erforderlich)

• Geschäftskontinuität für eigene Betriebsabläufe

• Alternative Arbeitsabläufe während Ausfällen

Kundenmaßnahmen bei Ausfällen
• Statusseite überwachen: onesurance
• Updates verfolgen: E-Mail-Benachrichtigungen
• Workarounds verwenden: Falls verfügbar
• Probleme melden: Über Supportkanäle
• Vermeiden: Übermäßige Wiederholungsversuche (können die Wiederherstellung verzögern)

Kunden-BC-Planung
• Dokumentation: Eigene BC-Pläne pflegen
• Abhängigkeiten: Onesurance die Risikobewertung einbeziehen
• Tests: Onesurance einbeziehen
• Kontakte: Kontaktlisten aktuell halten
• Eskalation: Wissen, wie Sie uns in Notfällen erreichen können

Kontakt

Für Geschäftskontinuität und Notfallwiederherstellung:
• 24/7-Hotline für Vorfälle: onesurance
• BC/DR-Planung: onesurance
• Fragen zum SLA: onesurance

Zuletzt aktualisiert: Dezember 2024
Onesurance .V. | Breda, Niederlande | Handelskammer: 87521997