Samuel Kraßnitzer
AI in Regulated Software Testing: What's Already Possible — and What Matters
AI is also finding its way into AI-powered software testing. In regulated industries, the reaction to this is often mixed: interest on the one hand,...
The Digital Operational Resilience Act (DORA, Regulation (EU) 2022/2554) has been in full effect since 17 January 2025. Unlike many regulatory initiatives, there were no phased transition periods. From ICT risk management and third-party ICT management to the resilience testing programme, all obligations took effect at once on the effective date. On the same effective date, BaFin repealed the VAIT guidelines, which had served as a reference for the industry for years.
Key points at a glance:
|
DORA applies in full to primary insurers and reinsurers alike, with no exceptions or grace periods. Many companies have not yet fully implemented their DORA roadmap. This is common and there is no reason for hasty action. A frequent structural reason for this is that DORA was set up like an IT project. However, critical functions are defined in business terms and the management body is responsible for them. |
|
DORA-compliant test management is an ongoing task that requires documentation, not a one-time acceptance process. It therefore belongs permanently within test management, rather than within a temporary implementation project. |
|
Evidence generated as a by-product of ongoing testing leads to audit readiness more quickly than documentation compiled retroactively shortly before an audit. |
A year and a half later, the situation on-the-ground is mixed. Some companies adapted their structures early on. In many others, however, DORA implementation is lagging behind the original plan in certain areas. For example, the information register is incomplete, legacy contracts with ICT service providers have not been renegotiated, and although there is a test programme, it has not yet been implemented. This is neither unusual nor the result of individual failings. DORA covers a wide range of topics, the text of the regulation is dense, and the requirements extend deep into the organisation.
Therefore, the interesting question is not who is behind schedule, but why implementation so often stalls. In our experience, a key reason for this lies in the project structure itself.
This article is aimed at board members, risk management teams, IT leaders and test managers at insurance companies and reinsurers — especially those who have not yet finalised their DORA roadmap.
Implementing DORA in the insurance industry: Why ICT governance is a top priority
In many companies, DORA was implemented in a similar manner to earlier IT regulations. Project management was handled by IT, the budget came from IT, and success criteria were measured using IT metrics. This is understandable, given that 'ICT' appears in nearly every article of the regulation. Nevertheless, this approach falls short for three reasons.
-
Firstly, responsibility explicitly lies with the management body. For example, Article 5 makes the executive board responsible for the ICT risk management framework, including approval, oversight and resources. This responsibility cannot be delegated to IT.
-
Second, the question of which functions are 'critical or important' is central to many DORA obligations. This is not a technical assessment, but a business one. Which failures would significantly impair business operations, financial stability or compliance with regulatory obligations? Neither the IT department nor the testing team can determine this alone. A criticality assessment absolutely requires the involvement of business units and risk management.
-
Thirdly, third-party ICT management has a much broader scope than just IT. Contract adjustments, exit strategies and concentration risks affect procurement, the legal department and the business units alike. For insurance groups and reinsurers operating internationally, there is also the question of how to harmonise group-wide testing programmes with national requirements in third countries. We will explore this issue in more detail in a separate article.
DORA-compliant test management: Resilience testing is an ongoing obligation that requires evidence
This is particularly evident in the context of testing. Article 24, for instance, requires a resilience testing programme to form an integral part of ICT risk management, which must be risk-based and prioritised. All ICT systems and applications that support critical or important functions must be tested at least once a year. Article 25 lists a wide range of possible tests: from vulnerability assessments through scenario-based tests, performance and end-to-end tests, to penetration tests.
This is not a one-off acceptance test at the end of a project, but a recurring process for which evidence must be provided. DORA thus has a profound impact on test management – an area that, when the DORA programme was first implemented, was only considered at a late stage, or not at all, in many organisations. Without a robust criticality assessment, there can be no robust test prioritisation. A test team that does not know which systems support critical functions will either test too much, which puts a strain on the budget, or too little, which, in the long run, may prove significantly more expensive.
In practical terms, this also means that established test artefacts take on a regulatory function. A test strategy is no longer merely an internal governance document, but rather proof that the company conducts testing in a risk-based and systematic manner. Test concepts, test plans, status reports and final reports become audit-ready test documentation and verifiable evidence. The key lies in ensuring that this compliance documentation emerges as a natural outcome of the testing work – rather than being compiled retrospectively when someone asks for it.
Proportionality, TLPT and Solvency II synergies: What Does DORA mean specifically for Insurers and Reinsurers?
Not all DORA requirements affect insurers and reinsurers in the same way. The competent European supervisory authority is EIOPA. The principle of proportionality means that the effort and depth of testing can be tailored to the size and risk profile of the institution. Smaller insurers may even fall entirely outside the scope of application based on Solvency II thresholds.
A common misunderstanding concerns threat-led penetration testing (TLPT). This resource-intensive form of advanced security testing is only mandatory for companies identified as such by the supervisory authorities. According to the regulatory criteria, this applies to only a small proportion of insurers and reinsurers. However, they are not exempt from traditional security and resilience tests, which remain in effect. By clearly distinguishing between these requirements, companies can avoid allocating scarce resources to those that do not apply to their business.
It is also important to coordinate with existing Solvency II processes, such as the company’s own risk and solvency assessment (ORSA). Much of the information regarding operational risk is already documented there; duplicative documentation ties up capacity without increasing maturity levels. Companies that consistently leverage these synergies will improve efficiency while simultaneously strengthening their operational resilience.
DORA roadmap behind schedule: Risk-Based Prioritisation Instead of Reactive Measures
The past effective date cannot be changed. However, what can be changed is how we deal with it. Based on our project experience, knee-jerk reactions rarely lead to robust results. It makes more sense to take a level-headed, risk-based step back:
-
Where are the biggest gaps in evidence?
-
Which critical or important functions are truly affected?
-
What test documentation already exists that simply needs to be consolidated rather than recreated?
A structured DORA gap analysis often reveals that the situation is better than expected, as substantial work is already underway in ongoing testing operations — it simply hasn’t yet been structured in accordance with DORA. The business impact is significant. Evidence gathered only after the fact significantly increases the risk of regulatory findings and the effort required during audits.
Conversely, a well-structured, continuous testing programme pays off twice over: It meets regulatory requirements while simultaneously strengthening the operational resilience on which the business relies in areas such as new business, claims processing and customer contact. In this way, DORA evolves from a mandatory requirement into a capability that supports the company sustainably.
Systematically assess DORA maturity levels and efficiently close documentation gaps
We support insurers and reinsurers by reviewing their existing test documentation to ensure DORA compliance. Gaps in evidence are prioritised on a risk-based basis, and test management is structured so that regulatory requirements are met as part of ongoing testing operations.
Contact us to arrange an initial, no-obligation consultation to discuss your testing programme's current status, the most effective next steps and what a DORA gap analysis might entail for your company.
Digital Accessibility in Practice: Impressions from the BAMF Power Tutorial
What can we learn about accessibility testing? What about tools? And attitude? All this was covered at the German Testing Night. Imagine trying to...
LLM Security: Why Traditional Security Testing Is Not Enough for AI Applications
For thirty years, application security has rested on a simple architectural assumption: code and user input are fundamentally separate entities, and...