Testautomatisierung in der Versicherung muss seit dem 17. Januar 2025 die DORA-Pflicht zu mindestens jährlichen Tests kritischer IT-Systeme erfüllen, und das auf Kernsystemen, die für Automatisierung nie ausgelegt waren. Beitragsberechnungen müssen exakt sein, Beratungsstrecken konform, und Solvency II verlangt korrekte Daten für Rückstellungen. Dieser Beitrag zeigt, warum Testautomatisierung in der Versicherung besonders schwierig ist und wie sie trotz Legacy-Cores 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).

Versicherer betreiben Policenverwaltung, Schadenbearbeitung und Beitragsberechnung meist auf jahrzehntealten Kernsystemen mit Batch-Verarbeitung statt moderner Schnittstellen. Genau diese Systeme sind schwer automatisiert zu testen.

Der World Quality Report 2024-25 belegt 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). Die Zahlen stammen aus einer Herstellerumfrage, decken sich aber mit der Realität der Branche.

Warum manueller Test nicht mehr reicht

Manuelles Testen kann die DORA-Pflicht zu mindestens jährlichen Tests aller kritischen Funktionen über gewachsene Systemlandschaften nicht wirtschaftlich erfüllen. 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 (Digital Operational Resilience Act) ist eine EU-Verordnung, die von Finanzunternehmen ein risikobasiertes, nachweisbares Programm zum Testen ihrer IT-Systeme verlangt. Artikel 24 fordert mindestens jährliche Tests aller kritischen Funktionen; Artikel 25 nennt End-to-End- und Performance-Tests ausdrücklich als erwartete Testarten.

Die bisherigen IT-Rundschreiben der Aufsicht entfielen dafür. Laut BaFin gilt: „Diese Rundschreiben hebt die BaFin mit Ablauf des 16. Januar 2025 auf” (2025).

Hinzu kommt Solvency II. Diese EU-Aufsichtsrichtlinie verlangt in Artikel 82 korrekte, vollständige und angemessene Daten für versicherungstechnische Rückstellungen (EUR-Lex). Rechenkern und Datenpipelines werden damit zu Compliance-Themen. Manuelles Testen kann diese jährliche, datengetriebene Nachweispflicht über komplexe Systemlandschaften kaum wirtschaftlich erbringen.

Was DORA Artikel 24 und 25 konkret verlangen

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

DORA Artikel 24 und 25 verlangen von Versicherern vier prüfbare Dinge: jährliche Tests kritischer Funktionen, definierte Testarten, risikobasierten Umfang und prüffähige Protokollierung. Für die Teststrategie eines Versicherers lassen sich die 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 stellt fünf Prüfanforderungen, die über klassische Funktionstests hinausgehen: Rechenkorrektheit, End-to-End-Strecken, Datenmigration, Beratungskonformität und Datenschutz.

• 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.

Risikobasierte Testautomatisierung konzentriert den Aufwand auf die Strecken, deren Fehler am teuersten sind, und erfüllt so DORA und Solvency II wirtschaftlich. Vollautomatisierung um jeden Preis ist nicht das Ziel. Bewährt hat sich diese Reihenfolge:

KI senkt den Aufwand für wiederholbare Tests spürbar, wie der praktische Leitfaden zur KI-gestützten Testautomatisierung zeigt. Sie 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.