In regulierten Branchen entscheidet nicht nur, ob Software funktioniert, sondern ob Sie es lückenlos beweisen können. Banken, Versicherer, Pharma- und Medizintechnikunternehmen testen nicht für sich selbst, sondern für Aufsichtsbehörden, Auditoren und am Ende für ihre Kunden. Ein einzelner nicht nachvollziehbarer Testlauf kann ein Audit kippen. Dieser Leitfaden ordnet den regulatorischen Rahmen ein und zeigt, wie Sie eine Teststrategie aufbauen, die sowohl prüffähig als auch wirtschaftlich automatisierbar ist.

Kurz gefasst: Testen in regulierten Branchen bedeutet, jede Prüfung so zu dokumentieren, dass sie nachvollziehbar, reproduzierbar und revisionssicher ist. Seit dem 17. Januar 2025 verlangt DORA von Banken und Versicherern ein risikobasiertes Testprogramm mit mindestens jährlichen Tests aller kritischen ICT-Systeme – Automatisierung und Audit-Trails werden damit zur Pflicht, nicht zur Kür.

Abbildung 1: Testen in regulierten Branchen – Beweislast statt blossem Funktionstest.

Was bedeutet Testen in regulierten Branchen?

Testen in regulierten Branchen ist die Disziplin, Software so zu prüfen und zu dokumentieren, dass die Ergebnisse einem externen Audit standhalten. Der Unterschied zum klassischen Softwaretest liegt nicht in den Testtechniken selbst, sondern in der Beweislast: Jeder Testfall muss einer Anforderung zuordenbar sein, jede Ausführung nachvollziehbar protokolliert, jedes Ergebnis reproduzierbar.

Diese Anforderung trifft Organisationen, deren Software unter Aufsicht steht – Finanzdienstleister, Versicherer, Pharma- und Medizintechnikhersteller, kritische Infrastruktur und zunehmend Betreiber von Hochrisiko-KI-Systemen. Für sie ist ein bestandener Test ohne sauberen Nachweis wertlos. Die Grundlagen dazu fassen wir im Beitrag Software-Testing: Grundlagen, Prozess und Methoden zusammen; dieser Leitfaden setzt darauf auf und fokussiert auf den regulatorischen Kontext.

Warum regulierte Branchen andere Teststandards brauchen

Abbildung 3: Was schlecht getestete Software kostet – TSB-Bussgeld und CISQ-Schadenssumme.

Der Grund ist die Konsequenz von Fehlern. Schlechte Softwarequalität kostete allein in den USA 2022 mindestens 2,41 Billionen US-Dollar (CISQ, 2022). In regulierten Sektoren kommen zu den direkten Kosten Bussgelder, Reputationsschäden und der Entzug von Betriebserlaubnissen hinzu.

Ein lehrreiches Beispiel ist die TSB-Bankenmigration von 2018: Die britischen Aufsichtsbehörden FCA und PRA verhängten dafür im Dezember 2022 ein Bussgeld von 48,65 Millionen Pfund. Ein unabhängiges Review hielt fest, dass zwei Rechenzentren vor der Migration „überhaupt nicht getestet” worden waren (FCA, 2022). Nicht der Code allein war das Problem, sondern die fehlende, nachweisbare Testabsicherung.

Der regulatorische Rahmen: DORA, FINMA, EU AI Act und GxP

Abbildung 2: Der regulatorische Rahmen und seine Testpflichten im Ueberblick.

Der wichtigste Wandel der letzten Jahre: In Deutschland und der EU haben die alten IT-Aufsichtsrundschreiben ausgedient. Die BaFin-Rundschreiben BAIT, VAIT und KAIT wurden durch DORA abgelöst, das seit dem 17. Januar 2025 unmittelbar gilt; BAIT wird vollständig zum Ende 2026 aufgehoben (Bundesbank, 2025). Wer noch auf VAIT verweist, arbeitet mit veralteten Vorgaben.

DORA ist dabei der Taktgeber. Artikel 24 verlangt ein „solides und umfassendes” Testprogramm; Artikel 25 nennt ausdrücklich End-to-End-Tests, Performance-Tests und Quellcode-Reviews als erwartete Testarten; Artikel 26 schreibt bedrohungsgeleitete Penetrationstests (TLPT) mindestens alle drei Jahre vor (EUR-Lex 2022/2554, 2022). Damit ist regelmässiges, dokumentiertes Testen keine interne Best Practice mehr, sondern eine aufsichtsrechtliche Pflicht.

Revisionssichere Testdokumentation und Audit-Trails

Das Herzstück jeder Compliance-Teststrategie ist der Nachweis. Ein Audit-Trail muss zeigen, wer wann was geprüft hat – und dass das Ergebnis nicht nachträglich verändert wurde. Die FDA verlangt in 21 CFR Part 11 ausdrücklich „sichere, computergenerierte, mit Zeitstempel versehene Audit-Trails” (eCFR). Das verbindende Prinzip über alle Branchen heisst ALCOA+: Daten müssen attributierbar, lesbar, zeitnah, original und korrekt sein – plus vollständig, konsistent, dauerhaft und verfügbar (MHRA, 2018).

Wie Sie solche Nachweise erzeugen, ohne Ihr Team in Dokumentation zu ertränken, behandeln wir vertieft im Beitrag Audit-Trail im Software-Testing: revisionssichere Dokumentation.

Computer System Validation in Pharma und Medizintechnik

In der Pharma- und Medizintechnik gilt eine eigene Logik: die Validierung computergestützter Systeme (CSV). Hier hat sich 2025 Grundlegendes geändert. Die FDA hat ihre Leitlinie „Computer Software Assurance” (CSA) am 24. September 2025 final veröffentlicht – sie ist also nicht mehr im Entwurfsstadium (Federal Register, 2025). CSA verschiebt den Fokus von erschöpfender Dokumentation hin zu risikobasiertem, kritischem Testen und erlaubt ausdrücklich auch unskriptierte Tests.

Die Details, inklusive GAMP 5 (2. Auflage), dem IQ/OQ/PQ-Modell und IEC 62304 für Medizinprodukte, vertiefen wir im Beitrag GxP-Testing und Computer System Validation (CSV).

DSGVO-konforme Testdaten

Ein oft unterschätztes Compliance-Risiko liegt in den Testdaten. Wer Produktivdaten mit Personenbezug in Test- oder QA-Umgebungen kopiert, verstösst in der Regel gegen den Grundsatz der Datenminimierung nach Artikel 5 DSGVO. Die spanische Datenschutzbehörde AEPD warnt, dass Vorproduktionsumgebungen oft schlechter geschützt sind als die Produktion – und empfiehlt ausdrücklich synthetische Testdaten (AEPD, 2022).

Wichtig: Pseudonymisierte Daten bleiben personenbezogene Daten und unterliegen weiterhin der DSGVO (EDPB, 2025). Wie Sie Testdaten rechtssicher und zugleich realistisch bereitstellen, zeigt der Beitrag DSGVO-konforme Testdaten: Testdatenmanagement in regulierten Branchen.

Testautomatisierung in Banken und Versicherungen

Gerade Banken und Versicherer stehen unter doppeltem Druck: hohe regulatorische Anforderungen treffen auf historisch gewachsene Kernsysteme. Im World Quality Report 2024-25 nennen 64 Prozent der Befragten Altsysteme als Hindernis für Automatisierung (Capgemini, 2024) – eine Herstellerumfrage, die sich aber mit der Realität dieser Branchen deckt.

Für die Bankenseite haben wir die Anforderungen in Testautomatisierung in regulierten Banken: audit-fähig unter DORA und FINMA ausgearbeitet; die Versicherungsperspektive – Solvency II, Legacy-Cores, Beitragsberechnungen – behandelt Testautomatisierung in der Versicherungsbranche. KI kann den Aufwand für wiederholbare Tests dabei spürbar senken, wie der praktische Leitfaden zur KI-gestützten Testautomatisierung zeigt – ersetzt aber weder Strategie noch Fachwissen.

So bauen Sie eine audit-fähige Teststrategie auf

Abbildung 4: In fuenf Schritten zur audit-faehigen Teststrategie.

Eine prüffähige Teststrategie entsteht nicht durch mehr Dokumentation, sondern durch strukturierte Nachvollziehbarkeit. Diese Schritte haben sich bewährt:

• Anforderungen verankern: Bauen Sie eine Anforderungs-Rückverfolgungsmatrix auf, die jeden Test einer regulatorischen oder fachlichen Anforderung zuordnet (Definition nach ISTQB).

• Risikobasiert priorisieren: Testen Sie kritische und wichtige Funktionen am intensivsten – so verlangt es DORA, und so sparen Sie Aufwand bei unkritischen Komponenten.

• Audit-Trails automatisieren: Lassen Sie Testläufe, Versionen und Ergebnisse automatisch und revisionssicher protokollieren, statt Screenshots zu sammeln.

• Testdaten entschärfen: Ersetzen Sie Produktivdaten durch synthetische oder anonymisierte Testdaten.

• Flaky Tests eliminieren: Nicht-deterministische Tests untergraben die Beweiskraft Ihrer Nachweise; Self-Healing Locators helfen, Tests stabil zu halten.

Wie Sie diese Schritte in einen durchgängigen, automatisierten Workflow überführen, zeigt unsere Übersicht zu Test-Workflows.

Häufig gestellte Fragen

Was bedeutet Compliance-Testing?

Compliance-Testing bezeichnet das Prüfen und Dokumentieren von Software so, dass die Ergebnisse regulatorischen Anforderungen genügen und einem Audit standhalten. Im Mittelpunkt stehen Nachvollziehbarkeit, Reproduzierbarkeit und revisionssichere Protokollierung – nicht nur die Frage, ob die Software funktioniert.

Welche Vorschrift gilt für IT-Tests in deutschen Banken seit 2025?

Seit dem 17. Januar 2025 gilt DORA unmittelbar. Die BaFin-Rundschreiben BAIT und VAIT wurden abgelöst; BAIT wird zum Ende 2026 vollständig aufgehoben. Banken und Versicherer richten ihr Testprogramm daher an DORA aus, nicht mehr an den alten *AIT-Rundschreiben.

Wie oft müssen kritische ICT-Systeme getestet werden?

DORA Artikel 24 verlangt für kritische und wichtige Funktionen mindestens jährliche Tests im Rahmen eines risikobasierten Testprogramms. Bedrohungsgeleitete Penetrationstests (TLPT) sind für bedeutende Institute zusätzlich mindestens alle drei Jahre vorgeschrieben.

Darf man Produktivdaten in Testumgebungen verwenden?

In der Regel nein. Der Einsatz personenbezogener Produktivdaten in Test- oder QA-Umgebungen widerspricht meist dem Grundsatz der Datenminimierung (Art. 5 DSGVO). Aufsichtsbehörden empfehlen synthetische oder anonymisierte Testdaten.

Ist die FDA-Leitlinie CSA noch ein Entwurf?

Nein. Die FDA hat „Computer Software Assurance” am 24. September 2025 als finale Leitlinie veröffentlicht. Sie ersetzt Abschnitt 6 der Leitlinie von 2002 und verfolgt einen risikobasierten, weniger dokumentationslastigen Ansatz.

Fazit

Regulierte Branchen verlangen einen Beweis, keine Behauptung. Wer in Banken, Versicherungen, Pharma oder Medizintechnik testet, muss jede Prüfung nachvollziehbar, reproduzierbar und revisionssicher belegen können – getrieben von DORA, FINMA, dem EU AI Act und den GxP-Regeln. Die gute Nachricht: Genau diese Anforderungen lassen sich heute weitgehend automatisieren. Strukturierte Rückverfolgbarkeit, risikobasierte Priorisierung und automatische Audit-Trails machen Compliance vom Bremsklotz zum Wettbewerbsvorteil. Wenn Sie Ihre Teststrategie über Web, Mobile, API und Desktop hinweg audit-fähig automatisieren möchten, sprechen Sie mit dem Autemos-Team über Ihren konkreten Anwendungsfall.