Non-life policy administration systems (property, homes and flats, vehicles) tend to be old, large and critical. Every change to a product, a tariff or a process touches them, and a bug shows up on real customers’ contracts. Since 2023 we have worked, through a partner company, directly in the project teams of several non-life insurers in Austria and Germany: Java development, IT and business analysis, changes to product and process modules, integrations, testing and documentation. This article is for architects, project leads and compliance people who need changes to arrive regularly and without surprises. It describes the rules we aim to follow in that environment and what regulation means for a development supplier.

What a policy administration system is and why it cannot be switched off

A policy administration system manages the life cycle of a contract: quotation and premium calculation, issuance, mid-term changes, renewals, cancellations and reversals. Around it sit other systems: rating, premium billing and collection, claims handling, accounting, document production and dispatch, portals for customers and intermediaries, reporting.

It cannot be switched off for several reasons at once. Intermediaries and portals conclude contracts in the evening and at weekends, claims are reported continuously, and outside business hours batch processing usually runs, for example renewals, premium billing or transfers to accounting. On top of that, Article 41(4) of the Solvency II Directive (2009/138/EC) requires an insurer to take reasonable steps to ensure continuity and regularity in the performance of its activities, including contingency plans. Deployments therefore use an agreed slot that does not clash with batch runs or business peaks.

A change has two halves and an effective date

Every requirement has a product part (what is insured, for how much, with which exclusions and riders) and a process part (how a contract is concluded, changed and renewed, and how a claim is reported). Analysis separates the two because they have different owners on the business side, different tests and different risks. We keep to the rule that a change without an owner who approves and accepts it is not started.

A product change almost always has an effective date. A new tariff applies to new contracts from a certain day, and possibly to renewals. Existing contracts stay on the terms under which they were written. For a mid-term change or a claim it must be possible to tell which product version was valid at the time. Product definitions are therefore versioned, not overwritten. A typical mistake is to test a new tariff only on new business and forget the mid-term change of an older contract that still runs on the previous version.

Release rhythm: calendar, change freeze, test window

Rhythm means a fixed deployment calendar, a fixed change-freeze date for each release and a fixed window for integration and acceptance testing. A change that misses the freeze goes into the next release. The team and the business know in advance what arrives when, testers work with a stable build, and surrounding systems can schedule their own changes for the same date. Predictability is worth more than the speed of any single change, because there are fewer last-minute additions just before go-live, and those tend to cause trouble.

The freeze cannot be absolute, though. A defect affecting customers or a security fix cannot wait for the next release. That is what a separate emergency-change path is for: smaller scope, faster approval and an obligation to document, assess and approve the change after the fact. It is not a loophole. Commission Delegated Regulation (EU) 2024/1774, which specifies the Digital Operational Resilience Act (DORA), explicitly requires procedures for emergency changes and their post-implementation review in Article 17. If the emergency path is routinely used for changes that simply missed the freeze, the rhythm falls apart. The fix then belongs in planning, and the process can stay as it is.

Interfaces and data: old and new run side by side for a while

Surrounding systems talk to the core through defined, versioned interfaces. A breaking interface change means a new version and a transition period when both run. Consumers migrate at their own pace, and the old version is switched off only after an agreed date and once it is confirmed that nobody calls it any more. A compatible extension, such as a new optional field, needs no new version if consumers can ignore it. An existing interface contract is never changed underneath a running system.

The same principle applies to the database and is known as expand/contract or parallel change. First the schema is extended so that both the old and the new application version work (a new column or table alongside the old ones). Then the data is backfilled in batches and the application moves to the new structure. The old parts are removed only in a later release. This makes it possible to roll the application back one version without touching the data. Feature toggles allow code to be deployed early and switched on at the effective date. They have a cost, however: each toggle can double the number of states that need validating, and a toggle left in the code after launch is technical debt. Each one therefore gets an owner and a removal date.

Testing: reference contracts and data without real customers

At the heart of regression testing is a set of reference contracts covering the products, tariff versions and typical events in a contract’s life: issuance, mid-term change, renewal, cancellation and a claim. Before and after the change, premiums are calculated and documents generated for them, and the results are compared. A difference is allowed only where the requirement expects one; any other difference is a finding. Test scenarios are linked to requirements, so that for every item in a release it can be said how it was verified and with what result.

The biggest trade-off is test data. A copy of production is realistic but contains customers’ personal data. Under the GDPR (Article 4(5), Recital 26), pseudonymised data is still personal data if additional information can attribute it to a specific person. Article 16 of Delegated Regulation (EU) 2024/1774 provides that financial entities’ non-production environments should store only anonymised, pseudonymised or randomised production data. An exception is possible only for specific testing occasions, for a limited period and with approval. A combination works well: synthetic contracts for regression and a pseudonymised slice of production for acceptance testing, protected as personal data deserves.

Going back: rollback or roll-forward

Every deployment record contains a rollback procedure that is prepared and, where possible, rehearsed in advance rather than improvised. Rolling code back one version is simple if the schema change was backward compatible. What the change did in the meantime is harder: recalculated premiums, issued policies, documents sent out and payment schedules are not undone by redeploying the old version.

So before the release we decide when a rollback makes sense and when a roll-forward does: a new small change that removes the defect, plus a correction of the affected contracts. That decision should not be made in the middle of the deployment. It belongs in the plan, together with the criterion that triggers going back (for example, failed post-deployment verification tests) and the name of the person who decides.

What regulation means for a development supplier

Since 17 January 2025, Regulation (EU) 2022/2554 on digital operational resilience for the financial sector (DORA) has applied. Insurance and reinsurance undertakings are financial entities under it (Article 2(1)(n)). Among insurers, only the small undertakings outside the scope of the Solvency II Directive under its Article 4 are excluded (Article 2(3)(b)). Germany’s BaFin repealed its IT requirements for insurers (VAIT) with effect from the end of 16 January 2025 to avoid overlap with DORA, and EIOPA withdrew its guidelines on ICT security and governance as of the same date. In Austria, the FMA is the competent authority for DORA. Alongside this, the Solvency II system of governance continues to apply, including written policies and outsourcing rules (Articles 41 and 49).

For a team delivering changes, the main expectations are these:

  • Change management: changes to ICT systems must be recorded, tested, assessed, approved, implemented and verified in a controlled manner (Article 9(4)(e) DORA). The function approving a change must be independent of those requesting and implementing it, and fall-back procedures must be identified for a change that fails (Article 17 of Regulation 2024/1774).
  • Testing: the depth of testing matches the criticality of the processes and assets. The procedure includes source code review with both static and dynamic testing, and, where feasible, third-party software is analysed and tested the same way before deployment to production (Article 16 of Regulation 2024/1774).
  • Incidents: deadlines for reporting a major incident to the supervisor are counted in hours. The insurer submits the initial notification within four hours of classification and, as a rule, no later than 24 hours after becoming aware of it (Article 5(1) of Delegated Regulation (EU) 2025/301). If the incident is classified as major only after those first 24 hours, Article 5(2) allows four hours from that later classification. A supplier must therefore be able to say straight away what was deployed when, who approved it and how it can be reversed.
  • Contracts: ICT service contracts must include the provider’s obligation to assist with an incident related to its service, at no additional cost or at a cost determined in advance (Article 30(2)(f) DORA), and the insurer keeps a register of all such contractual arrangements (Article 28(3)). When delivering through a partner company, it pays to know in advance which of these obligations reach you through the contractual chain.

Checklist before handing a change over to a release

  • The change has a business owner and an approved specification, including the effective date.
  • It is clear which product versions and which contracts it affects (new, renewing and in force).
  • The interface change is backward compatible, or there is a new version with a switch-off date for the old one.
  • The schema change has gone through the expand phase only, and removal of the old parts is scheduled for a later release.
  • Regression on the reference contracts shows no unexpected differences, and test results are mapped to requirements.
  • Test data contains no unprotected customer personal data.
  • The deployment record includes the rollback procedure, the criterion for triggering it and the choice between rollback and roll-forward.
  • The technical specification and operational documentation are updated before deployment, not after.

None of these rules is new and none of them requires heroics. Their value lies in being applied in every release, even under deadline pressure. If you are introducing changes into a core system, start with a release calendar with a clear emergency path, versioning of products and interfaces, and a deployment record with a prepared rollback. That covers a large part of what DORA expects for changes, and what remains is to complete the records and evidence. In a regulated environment, this kind of boring is what the client pays for.