·
9 min
Test Automation in the Insurance Industry
Roman Kirchmeier - Autemos
Since 17 January 2025, test automation in insurance must satisfy the DORA obligation to test critical IT systems at least yearly, on core systems that were never built for automation. Premium calculations must be correct, advice journeys compliant, and Solvency II requires accurate data for technical provisions. This article shows why test automation in insurance is especially hard and how to make it work despite legacy cores.
In brief: Since 17 January 2025, insurers must test their critical IT systems at least yearly under DORA, while Solvency II requires correct data for technical provisions. On grown legacy cores, this is only economically feasible with risk-based, audit-ready test automation.
Figure 1: Compliance meets legacy systems – risk-based automation as the way out.
The problem: compliance meets legacy systems
Figure 2: Legacy systems as the biggest automation barrier (World Quality Report 2024-25).
Insurers run policy administration, claims handling and premium calculation mostly on decades-old core systems with batch processing instead of modern interfaces. These very systems are hard to test automatically.
The World Quality Report 2024-25 confirms it: 64 percent of respondents name reliance on legacy systems as a barrier to automation, and 57 percent the absence of a comprehensive automation strategy (Capgemini, 2024). The figures come from a vendor survey, but they match the reality of the sector.
Why manual testing is no longer enough
Manual testing cannot economically meet the DORA obligation to test all critical functions at least yearly across grown system landscapes. Since 17 January 2025, DORA applies directly to insurers too and replaces the former VAIT circular in Germany (EIOPA, 2025; BaFin, 2025).
DORA (Digital Operational Resilience Act) is an EU regulation that requires financial entities to run a risk-based, demonstrable programme for testing their IT systems. Article 24 requires at least yearly tests of all critical functions; Article 25 explicitly names end-to-end and performance testing as expected test types. According to EIOPA, DORA "ensures that banks, insurance companies, investment firms and other financial entities can withstand, respond to, and recover from ICT disruptions, such as cyberattacks or system failures".
Add to this Solvency II. This EU supervisory directive requires in Article 82 that the data for technical provisions be accurate, complete and appropriate (EUR-Lex). The calculation engine and data pipelines become compliance concerns. Manual testing can hardly meet this yearly, data-driven obligation across complex system landscapes economically.
What DORA Articles 24 and 25 concretely require
Figure 3: The four concrete testing obligations from DORA Articles 24 and 25.
DORA Articles 24 and 25 require four testable things from insurers: yearly tests of critical functions, defined test types, risk-based scope, and auditable logging. For an insurer's test strategy, the requirements translate as follows (EUR-Lex 2022/2554, 2022):
Yearly evidence: Critical and important functions must be tested and documented at least once a year — not only once at introduction.
Defined test types: Article 25 explicitly names end-to-end and performance testing as well as source code reviews as expected methods.
Risk-based scope: Test effort scales with risk; the most business-critical journeys are tested most intensively.
Auditable logging: Results and remediation must be documented traceably for the supervisor.
These four obligations can hardly be met manually, year after year, across a grown system landscape. They are the real driver for automation in insurance.
The specific testing challenges of insurance
Insurance software brings five testing requirements that go beyond classic functional tests: calculation correctness, end-to-end journeys, data migration, advice compliance, and data protection.
Calculation correctness: Premium, tariff and reserve calculations must remain exact across all tariff changes — a classic case for regression testing.
End-to-end journeys: Application, policy issuance and claims pass through many systems; breaks only show in an end-to-end end-to-end test.
Data migration: When replacing legacy systems, migration assurance determines data quality — with direct Solvency II relevance.
Advice compliance: Suitability and product oversight (POG) logic under the Insurance Distribution Directive (IDD) must stay correct at every product and price change.
Data protection: Policy data is highly sensitive; tests must not use it unprotected (see GDPR-compliant test data).
The solution: risk-based, audit-ready automation
Figure 4: Five levers of risk-based, audit-ready test automation.
Risk-based test automation concentrates effort on the journeys whose failures are most expensive, and so meets DORA and Solvency II economically. Full automation at any cost is not the goal. This sequence has proven effective:
Lever | Effect |
|---|---|
Risk-based prioritisation | Automate critical journeys (premium, claims, reporting) first |
Stable locators | Less maintenance despite UI changes, e.g. via self-healing locators |
Automatic audit trails | The yearly DORA evidence as a by-product of the pipeline |
Compliant test data | Synthetic instead of real policy data |
AI-assisted authoring | Faster coverage of recurring test types |
AI noticeably reduces the effort for repeatable tests, as the practical guide to AI-powered test automation shows. It replaces neither the test strategy nor the expertise in insurance-specific logic.
In client projects in the regulated financial sector, we see that risk-based automation significantly reduces maintenance effort while easing the yearly evidence requirement, because test runs are logged tamper-evidently. The banking perspective is covered in Test Automation in Regulated Banks; the full regulatory frame is provided by Testing in Regulated Industries. How to bring this into an end-to-end flow is shown in our overview of test workflows.
Frequently asked questions
Does DORA apply to insurers too?
Yes. DORA has applied directly to insurance and reinsurance undertakings and insurance intermediaries since 17 January 2025 (with exceptions for microenterprises). In Germany it replaces BaFin's former VAIT circular.
Why is test automation in insurance so hard?
Many insurers run grown core systems with batch processing and without modern interfaces, often without existing automated regression suites. In the World Quality Report 2024-25, 64 percent of respondents name legacy systems as a barrier to automation.
Which insurance software should be automated first?
Priority goes to critical, data-driven journeys: premium and reserve calculation, end-to-end application and claims processes, and data migrations. They carry the highest regulatory and financial risk and benefit most from automation.
What role does Solvency II play in testing?
Solvency II Article 82 requires accurate, complete and appropriate data for technical provisions. This turns calculation-engine, data and migration testing into a compliance concern, not just a quality question.
Conclusion
In insurance, the highest regulatory demands meet the oldest systems, and this very balancing act makes test automation indispensable. DORA requires yearly, demonstrable tests of critical systems; Solvency II requires correct data. Those who automate by risk, maintain stable tests and generate audit trails automatically meet both requirements economically. If you want to automate your insurance software across web, mobile, API and desktop in an audit-ready way, talk to the Autemos team about your specific use case.
