·
9 min
Test Automation in the Insurance Industry
Roman Kirchmeier - Autemos
Insurers face a double burden: high regulatory demands meet decades-old core systems. Premium calculations must be correct, advice journeys compliant, and since 2025 DORA requires a demonstrable testing programme. This article shows why test automation in insurance is especially hard — and precisely for that reason especially valuable — and how to make it work.
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).
Few industries combine such high requirements with such old technology as insurance. Policy administration, claims handling and premium calculation often run on grown 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). This is a vendor survey, but it matches the reality of the sector.
Why manual testing is no longer enough
At the same time, regulatory demands are rising. Since 17 January 2025, DORA applies directly to insurers too and replaces the former VAIT circular in Germany (EIOPA, 2025; BaFin, 2025). DORA Article 24 requires a risk-based testing programme with at least yearly tests of all critical functions; Article 25 explicitly names end-to-end and performance testing as expected test types.
Add to this Solvency II: Article 82 requires that the data for technical provisions be accurate, complete and appropriate (EUR-Lex). The calculation engine and data pipelines are therefore not just quality concerns but 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.
Behind the paragraphs lie concrete, testable obligations. For an insurer's test strategy, the DORA requirements translate as follows (EUR-Lex 2022/2554, 2022):
1. Yearly evidence: Critical and important functions must be tested and documented at least once a year — not only once at introduction.
2. Defined test types: Article 25 explicitly names end-to-end and performance testing as well as source code reviews as expected methods.
3. Risk-based scope: Test effort scales with risk; the most business-critical journeys are tested most intensively.
4. 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 specific testing requirements that go beyond classic functional tests:
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.
The way out is not full automation at any cost, but a risk-based strategy that concentrates effort where failures are most expensive. 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 — but 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.
