Versicherer stehen unter doppeltem Druck: hohe regulatorische Anforderungen treffen auf jahrzehntealte Kernsysteme. Beitragsberechnungen müssen stimmen, Beratungsstrecken konform sein, und seit 2025 verlangt DORA ein nachweisbares Testprogramm. Dieser Beitrag zeigt, warum Testautomatisierung in der Versicherung besonders schwierig – und gerade deshalb besonders wertvoll – ist und wie sie gelingt.

Kurz gefasst: Versicherer müssen seit dem 17. Januar 2025 unter DORA ihre kritischen IT-Systeme mindestens jährlich testen, während Solvency II korrekte Daten für versicherungstechnische Rückstellungen verlangt. Auf gewachsenen Legacy-Cores ist das nur mit risikobasierter, audit-fähiger Testautomatisierung wirtschaftlich machbar.

Abbildung 1: Regulatorik trifft Altsysteme – risikobasierte Automatisierung als Ausweg.

Das Problem: Compliance trifft auf Altsysteme

Abbildung 2: Altsysteme als grösstes Automatisierungshindernis (World Quality Report 2024-25).

Kaum eine Branche verbindet so hohe Anforderungen mit so alter Technik wie die Versicherung. Policenverwaltung, Schadenbearbeitung und Beitragsberechnung laufen vielerorts auf gewachsenen Kernsystemen mit Batch-Verarbeitung statt moderner Schnittstellen. Genau diese Systeme sind schwer automatisiert zu testen.

Der World Quality Report 2024-25 bestätigt das: 64 Prozent der Befragten nennen die Abhängigkeit von Altsystemen als Hindernis für Automatisierung, 57 Prozent das Fehlen einer umfassenden Automatisierungsstrategie (Capgemini, 2024). Das ist eine Herstellerumfrage, deckt sich aber mit der Realität der Branche.

Warum manueller Test nicht mehr reicht

Gleichzeitig steigt der regulatorische Anspruch. Seit dem 17. Januar 2025 gilt DORA unmittelbar auch für Versicherer und löst in Deutschland das frühere VAIT-Rundschreiben ab (EIOPA, 2025; BaFin, 2025). DORA Artikel 24 verlangt ein risikobasiertes Testprogramm mit mindestens jährlichen Tests aller kritischen Funktionen; Artikel 25 nennt End-to-End- und Performance-Tests ausdrücklich als erwartete Testarten.

Hinzu kommt Solvency II: Artikel 82 verlangt, dass die Daten für versicherungstechnische Rückstellungen korrekt, vollständig und angemessen sind (EUR-Lex). Rechenkern und Datenpipelines sind damit nicht nur Qualitäts-, sondern Compliance-Themen. Manuelles Testen kann diese jährliche, datengetriebene Nachweispflicht über komplexe Systemlandschaften kaum wirtschaftlich erfüllen.

Was DORA Artikel 24 und 25 konkret verlangen

Abbildung 3: Die vier konkreten Testpflichten aus DORA Artikel 24 und 25.

Hinter den Paragrafen stehen konkrete, prüfbare Pflichten. Für die Teststrategie eines Versicherers lassen sich die DORA-Anforderungen so übersetzen (EUR-Lex 2022/2554, 2022):

1. Jährlicher Nachweis: Kritische und wichtige Funktionen müssen mindestens einmal pro Jahr getestet und dokumentiert werden – nicht nur einmalig bei der Einführung.

2. Definierte Testarten: Artikel 25 nennt ausdrücklich End-to-End- und Performance-Tests sowie Quellcode-Reviews als erwartete Verfahren.

3. Risikobasierter Umfang: Der Prüfaufwand richtet sich am Risiko aus; die geschäftskritischsten Strecken werden am intensivsten getestet.

4. Prüffähige Protokollierung: Ergebnisse und Mängelbehebung müssen für die Aufsicht nachvollziehbar dokumentiert sein.

Diese vier Pflichten lassen sich manuell kaum jährlich über eine gewachsene Systemlandschaft erbringen – sie sind der eigentliche Treiber für Automatisierung in der Versicherung.

Die besonderen Testherausforderungen der Versicherung

Versicherungssoftware bringt spezifische Prüfanforderungen mit, die über klassische Funktionstests hinausgehen:

• Rechenkorrektheit: Beitrags-, Tarif- und Rückstellungsberechnungen müssen über alle Tarifänderungen hinweg exakt bleiben – ein klassischer Fall für Regressionstests.

• End-to-End-Strecken: Antrag, Policierung und Schadenfall durchlaufen viele Systeme; Brüche zeigen sich nur im durchgängigen End-to-End-Test.

• Datenmigration: Bei der Ablösung von Altsystemen entscheidet die Migrationssicherheit über die Datenqualität – mit direkter Solvency-II-Relevanz.

• Konformität der Beratung: Eignungs- und Produktfreigabelogik (POG) nach der Versicherungsvertriebsrichtlinie IDD muss bei jedem Produkt- und Preiswechsel korrekt bleiben.

• Datenschutz: Bestandsdaten sind hochsensibel; Tests dürfen sie nicht ungeschützt verwenden (siehe DSGVO-konforme Testdaten).

Die Lösung: risikobasierte, audit-fähige Automatisierung

Abbildung 4: Fünf Hebel risikobasierter, audit-fähiger Testautomatisierung.

Der Ausweg ist keine Vollautomatisierung um jeden Preis, sondern eine risikobasierte Strategie, die den Aufwand dort konzentriert, wo Fehler am teuersten sind. Bewährt hat sich diese Reihenfolge:

KI senkt dabei den Aufwand für wiederholbare Tests spürbar, wie der praktische Leitfaden zur KI-gestützten Testautomatisierung zeigt – ersetzt aber weder die Teststrategie noch das Fachwissen über versicherungsfachliche Logik.

In Kundenprojekten im regulierten Finanzsektor sehen wir, dass risikobasierte Automatisierung den Wartungsaufwand deutlich senkt und zugleich den jährlichen Nachweis erleichtert, weil Testläufe revisionssicher protokolliert werden. Die Bankenperspektive vertieft der Beitrag Testautomatisierung in regulierten Banken; den regulatorischen Gesamtrahmen liefert Testen in regulierten Branchen. Wie sich das in einen durchgängigen Ablauf bringen lässt, zeigt unsere Übersicht zu Test-Workflows.

Häufig gestellte Fragen

Gilt DORA auch für Versicherer?

Ja. DORA gilt seit dem 17. Januar 2025 unmittelbar auch für Versicherungs- und Rückversicherungsunternehmen sowie Versicherungsvermittler (mit Ausnahmen für Kleinstunternehmen). In Deutschland löst es das frühere VAIT-Rundschreiben der BaFin ab.

Warum ist Testautomatisierung in der Versicherung so schwierig?

Viele Versicherer betreiben gewachsene Kernsysteme mit Batch-Verarbeitung und ohne moderne Schnittstellen, oft ohne bestehende automatisierte Regressionssuiten. Im World Quality Report 2024-25 nennen 64 Prozent der Befragten Altsysteme als Automatisierungshindernis.

Welche Versicherungssoftware sollte zuerst automatisiert getestet werden?

Priorität haben kritische, datengetriebene Strecken: Beitrags- und Rückstellungsberechnung, durchgängige Antrags- und Schadenprozesse sowie Datenmigrationen. Sie tragen das höchste regulatorische und finanzielle Risiko und profitieren am stärksten von Automatisierung.

Welche Rolle spielt Solvency II beim Testen?

Solvency II Artikel 82 verlangt korrekte, vollständige und angemessene Daten für versicherungstechnische Rückstellungen. Damit werden Rechenkern-, Daten- und Migrationstests zu einem Compliance-Thema, nicht nur zu einer Qualitätsfrage.

Fazit

In der Versicherung treffen die höchsten regulatorischen Anforderungen auf die ältesten Systeme – und genau dieser Spagat macht Testautomatisierung unverzichtbar. DORA verlangt jährliche, nachweisbare Tests kritischer Systeme, Solvency II korrekte Daten. Wer risikobasiert automatisiert, stabile Tests pflegt und Audit-Trails automatisch erzeugt, erfüllt beide Anforderungen wirtschaftlich. Wenn Sie Ihre Versicherungssoftware über Web, Mobile, API und Desktop hinweg audit-fähig automatisieren möchten, sprechen Sie mit dem Autemos-Team über Ihren konkreten Anwendungsfall.