KI im Software-Testing: Was im regulierten Umfeld heute möglich ist.
Künstliche Intelligenz hält auch im Software-Testing Einzug. In regulierten Branchen ist die Reaktion darauf oft gemischt: Interesse auf der einen...

Praxisnah. Erfolgsbewährt. Maßgeschneidert. Erfahren Sie mehr über unsere Case Studies.
4 Min. Lesezeit
Samuel Kraßnitzer
:
Mittwoch, 15.7.2026
Seit dem 17. Januar 2025 ist der Digital Operational Resilience Act (DORA, Verordnung (EU) 2022/2554) in voller Gänze anzuwenden. Anders als bei vielen regulatorischen Vorhaben gab es keine gestaffelten Übergangsfristen: Mit dem Geltungsbeginn galten sämtliche Pflichten auf einmal – vom IKT-Risikomanagement über das IKT-Drittparteienmanagement bis hin zum Resilienztestprogramm. Die VAIT, an denen sich die Branche jahrelang orientiert hatte, wurden zum selben Stichtag von der BaFin aufgehoben.
Das Wichtigste auf einen Blick:
|
DORA gilt vollständig für Erst- und Rückversicherer gleichermaßen, ohne Ausnahmen oder Nachfristen. Viele Unternehmen haben ihren DORA-Fahrplan noch nicht vollständig abgearbeitet. Das ist verbreitet und kein Grund für Aktionismus. Ein häufiger struktureller Grund: DORA wurde wie ein IT-Projekt aufgesetzt. Kritische Funktionen werden aber fachlich definiert, und die Verantwortung liegt beim Leitungsorgan. |
|
DORA-konformes Testmanagement ist keine einmalige Abnahme, sondern eine nachweispflichtige Daueraufgabe. Sie gehört deshalb dauerhaft ins Testmanagement und nicht in ein befristetes Umsetzungsprojekt. |
|
Nachweise, die als Nebenprodukt der laufenden Testarbeit entstehen, führen schneller zur Auditfähigkeit als eine Dokumentation, die kurz vor einer Prüfung nachträglich zusammengestellt wird. |
Eineinhalb Jahre später zeigt sich in der Praxis ein gemischtes Bild. Einige Unternehmen haben ihre Strukturen früh angepasst. Bei vielen anderen sehen wir, dass die DORA-Umsetzung an einzelnen Stellen hinter dem ursprünglichen Plan zurückliegt. So ist das Informationsregister lückenhaft, Altverträge mit IKT-Dienstleistern wurden nicht nachverhandelt und das Testprogramm existiert zwar als Dokument, wird aber noch nicht umgesetzt. Das ist weder ungewöhnlich noch ein Versäumnis Einzelner. DORA ist breit gefächert, der Verordnungstext dicht und die Anforderungen reichen tief in die Organisation hinein.
Die interessante Frage ist deshalb nicht, wer im Verzug ist, sondern warum die Umsetzung so oft ins Stocken gerät. Ein wesentlicher Grund liegt unserer Erfahrung nach in der Projektaufstellung selbst.
Dieser Beitrag richtet sich an Vorstände, die Risikoebene, IT-Leitungen sowie Testmanagerinnen und Testmanager in Versicherungsunternehmen und Rückversicherern – insbesondere an jene, die ihren DORA-Fahrplan noch nicht vollständig abgearbeitet haben.
In vielen Unternehmen wurde DORA ähnlich wie frühere IT-Regulatorik umgesetzt: Die Projektleitung lag in der IT, das Budget stammte aus der IT und die Erfolgskriterien wurden anhand von IT-Kennzahlen gemessen. Das ist nachvollziehbar, schließlich steht „IKT“ in fast jedem Artikel der Verordnung. Dennoch greift dies aus drei Gründen zu kurz:
Erstens liegt die Verantwortung ausdrücklich beim Leitungsorgan. So macht Artikel 5 den Vorstand für den IKT-Risikomanagementrahmen verantwortlich, für Genehmigung, Überwachung und Ressourcen. Diese Verantwortung lässt sich nicht an die IT delegieren.
Zweitens ist die Frage, welche Funktionen „kritisch oder wichtig“ sind, der Dreh- und Angelpunkt vieler DORA-Pflichten. Dies ist keine technische, sondern eine geschäftliche Bewertung: Welcher Ausfall würde die Geschäftstätigkeit, die finanzielle Stabilität oder die Einhaltung aufsichtsrechtlicher Pflichten erheblich beeinträchtigen? Ob die Bestandsführung, das Schadensystem oder das Kundenportal darunterfallen, können weder die IT noch das Testteam allein beantworten. Die Kritikalitätsbewertung erfordert zwingend die Fachbereiche und das Risikomanagement.
Drittens reicht das IKT-Drittparteienmanagement weit über die IT hinaus: Vertragsanpassungen, Ausstiegsstrategien und Konzentrationsrisiken betreffen den Einkauf, die Rechtsabteilung und die Fachbereiche gleichermaßen. Für international aufgestellte Versicherungsgruppen und Rückversicherer stellt sich zusätzlich die Frage, wie gruppenweite Testprogramme mit nationalen Anforderungen in Drittstaaten harmonisiert werden. Diesen Aspekt werden wir in einem separaten Beitrag vertiefen.
Dies wird besonders deutlich beim Testen. So verlangt Artikel 24 ein Programm für Resilienztests als festen Bestandteil des IKT-Risikomanagements, das risikobasiert und priorisiert ist. Alle IKT-Systeme und -Anwendungen, die kritische oder wichtige Funktionen unterstützen, sind mindestens jährlich zu testen. Artikel 25 nennt ein breites Spektrum möglicher Tests: von Schwachstellenbewertungen über szenariobasierte Tests, Leistungs- und End-to-End-Tests bis hin zu Penetrationstests.
Dabei handelt es sich nicht um eine Abnahme am Projektende, sondern um einen wiederkehrenden, nachweispflichtigen Prozess. Damit greift DORA tief in das Testmanagement ein – einen Bereich, der beim Aufsetzen des DORA-Programms in vielen Unternehmen erst spät oder gar nicht berücksichtigt wurde. Ohne eine belastbare Kritikalitätsbewertung gibt es keine belastbare Testpriorisierung. Ein Testteam, das nicht weiß, welche Systeme kritische Funktionen stützen, testet entweder zu viel, was das Budget belastet, oder zu wenig, was im Zweifel deutlich teurer wird.
Praktisch bedeutet das auch, dass etablierte Testartefakte eine regulatorische Funktion erhalten. Eine Teststrategie ist dann nicht mehr nur ein internes Steuerungsdokument, sondern der Nachweis, dass das Unternehmen risikobasiert und systematisch testet. Testkonzepte, Testpläne, Statusberichte und Abschlussberichte werden zu auditfähiger Testdokumentation und prüfungsfähigen Belegen. Der wichtigste Hebel besteht darin, diese Compliance-Dokumentation als natürliches Ergebnis der Testarbeit entstehen zu lassen und sie nicht erst zusammenzustellen, wenn jemand danach fragt.
Nicht jede DORA-Anforderung betrifft Versicherer und Rückversicherer in gleicher Form. Zuständige europäische Aufsichtsbehörde ist die EIOPA. Das Proportionalitätsprinzip erlaubt es, Aufwand und Prüftiefe an Größe und Risikoprofil auszurichten. Kleinere Versicherer können über die Solvency-II-Schwellenwerte sogar ganz aus dem Anwendungsbereich fallen.
Ein häufiges Missverständnis betrifft das bedrohungsgeleitete Penetrationstesten (Threat-Led Penetration Testing, TLPT). Diese aufwendige Form fortgeschrittener Sicherheitstests ist nur für Unternehmen verpflichtend, die von den Aufsichtsbehörden dafür identifiziert werden. Nach den Kriterien der Verordnung betrifft das nur einen kleinen Teil der Versicherer und Rückversicherer. Dies entbindet jedoch nicht von den klassischen Sicherheits- und Resilienztests, die weiterhin gelten. Wer hier sauber abgrenzt, vermeidet, dass knappe Ressourcen für Anforderungen aufgewendet werden, die auf das eigene Unternehmen nicht zutreffen.
Ebenso wichtig ist die Abstimmung mit den bestehenden Solvency-II-Prozessen, wie dem ORSA (Own Risk and Solvency Assessment), der unternehmenseigenen Risiko- und Solvabilitätsbeurteilung. Vieles zum operationellen Risiko ist dort bereits dokumentiert und doppelte Nachweise binden Kapazität, ohne den Reifegrad zu erhöhen. Wer diese Synergien konsequent nutzt, schafft Effizienz und stärkt gleichzeitig die operative Resilienz des Unternehmens.
Der zurückliegende Geltungsbeginn lässt sich nicht ändern. Was sich jedoch ändern lässt, ist der Umgang damit. Aus unserer Projekterfahrung heraus führt Aktionismus selten zu belastbaren Ergebnissen. Sinnvoller ist ein nüchterner, risikobasierter Schritt zurück:
Wo bestehen die größten Nachweislücken?
Welche kritischen oder wichtigen Funktionen sind wirklich betroffen?
Welche Testdokumentation existiert bereits und muss nur konsolidiert statt neu erstellt werden?
Eine strukturierte DORA-Gap-Analyse zeigt häufig, dass die Lage besser ist als gedacht, da im laufenden Testbetrieb bereits Substanz vorhanden ist, die nur noch nicht im Sinne von DORA strukturiert wurde. Der geschäftliche Hebel ist beträchtlich. Eine erst nachträglich zusammengetragene Nachweislage erhöht das Risiko aufsichtlicher Feststellungen und den Aufwand bei Prüfungen spürbar.
Umgekehrt zahlt sich ein gut strukturiertes, kontinuierliches Testprogramm doppelt aus: Es erfüllt die regulatorischen Anforderungen und stärkt zugleich die operative Resilienz, auf die das Geschäft ohnehin angewiesen ist – im Neugeschäft, in der Schadenbearbeitung und im Kundenkontakt. So wird DORA vom Pflichtthema zu einer Fähigkeit, die das Unternehmen dauerhaft trägt.
Wir unterstützen Versicherer und Rückversicherer dabei, ihre bestehende Testdokumentation auf DORA-Tauglichkeit zu prüfen, Nachweislücken risikobasiert zu priorisieren und das Testmanagement so aufzustellen, dass die regulatorischen Anforderungen aus dem laufenden Testbetrieb heraus erfüllt werden.
Sprechen Sie uns an, um in einem ersten, unverbindlichen Gespräch zu erörtern, wo Ihr Testprogramm heute steht, welche Schritte den größten Hebel haben und wie eine DORA-Gap-Analyse in Ihrem Unternehmen aussehen kann.
Künstliche Intelligenz hält auch im Software-Testing Einzug. In regulierten Branchen ist die Reaktion darauf oft gemischt: Interesse auf der einen...
Im traditionellen Softwarekontext wird Qualitätssicherung häufig auf funktionale Tests und Bug-Fixing reduziert. Die Entwicklung liefert Code, die...
Was ein Abend bei der German Testing Night über Accessibility Testing, Tools und Haltung lehrt Stellen Sie sich vor, Sie bedienen Ihr Smartphone,...