Release Evidence in Insurance: What it is and Why it Matters

Release evidence is the connected chain that proves an insurance software release was verified: which requirements it covered, which tests proved them, what changed, who approved it and whether the results reproduce.

It is produced as the work happens, so the answer exists before an auditor, supervisor or board member thinks to ask.

Most insurers already have things that look like evidence. There is a test management system full of cases, a CI dashboard of green builds, a SharePoint folder of UAT screenshots and a change ticket with an approval on it. Each is useful. None of them, alone or together, answers the question that matters after an incident or during an audit: was the thing that went wrong actually tested, against what, and who decided it was ready? When answering that takes three weeks of interviews and spreadsheet archaeology, the firm does not have evidence. It has a reconstruction.

Why Do Insurers Need Release Evidence Now?

Because three things changed at once.

• Insurers take more change, from more directions, than their testing was designed for.

• Regulators moved from checking activity to asking about outcomes and controls.

• The cost of a pricing or wording defect is now public, measurable and paid back to customers with interest.

1. More Change, From More Directions

Core platforms have moved to fixed release calendars. Guidewire ships three cloud releases a year; Duck Creek ships three feature releases a year with monthly updates in between. Each release can move screens, APIs and default behaviour under a configured product.

For teams running PolicyCenter, ClaimCenter and BillingCenter, what each of those releases means for the regression pack is covered in our guide to Guidewire testing.

At the same time, pricing and product teams change rating tables, rules and forms through configuration screens, and engineering teams write more code, faster, with AI assistance. When the same kind of system that writes the code also writes the tests, a passing suite proves less than it used to. Somebody independent of the change has to decide what “correct” means and confirm it was checked.

That independence problem gets sharper in regulated firms, and testing AI-generated code in regulated industries sets out who should own the definition of “correct” when AI writes both sides.

2. Regulators Ask About Outcomes and Controls

The FCA’s Consumer Duty, which applied to open products from 31 July 2023 and to closed books from 31 July 2024, expects firms to monitor whether customers actually receive good outcomes, with the board reviewing an assessment at least annually. A system that miscalculates a refund or suppresses a renewal notice field is an outcome failure, not just a defect.

How the Duty’s outcome tests translate into specific checks on quotes, renewals and communications is the subject of our piece on Consumer Duty and software testing.

For UK home and motor insurance, ICOBS 6B requires that a renewal price is no higher than the equivalent new business price (ENBP), calculated at the point the renewal notice is prepared. Firms must keep documentation showing how they set renewal prices, and a senior manager attests to compliance each year. That is a direct expectation that pricing logic is controlled and that the control can be shown.

Because that attestation sits with a named individual, it ties directly to the accountability questions explored in SM&CR and AI accountability.

In the EU, DORA has applied to insurers within Solvency II scope since 17 January 2025 and requires a documented digital operational resilience testing programme. In the US, the NAIC’s model bulletin on insurers’ use of AI systems, adopted in December 2023 and taken up by many states, expects a written governance programme and warns that insurers may be asked for documentation in an investigation or market conduct action.

None of these rules tells an insurer how to test. All of them make it costly to be unable to show what was tested.

3. Implementation Errors Have a Price

When the UK pricing rules took effect in January 2022, insurers rebuilt renewal pricing logic at speed. In 2023 one large UK motor and home insurer agreed a voluntary requirement with the FCA after an error in implementing its ENBP calculation meant some renewing customers paid more than they should have. Estimated redress was around £30 million, and the firm had to review past business to find every affected customer. A separate ombudsman decision describes another insurer correcting premiums after an algorithm error in its implementation of the same rules.

Neither public account says what testing took place. What both show is the cost of a pricing rule implemented slightly wrong, and the size of the job afterwards: working out which releases changed the logic, which customers each release touched, and whether the fix is itself correct. Release evidence makes that job a query instead of a project.

What is Release Evidence Not?

Release evidence is not a test report, an audit log, a coverage percentage, a folder of UAT screenshots or a change ticket approval. Each shows that some activity happened; none connects an insurer’s business rule to the test that proves it, the change that touched it and the person who approved the release.

Most insurers hold all five. The gap is the thread that ties them together.

What Questions Must Release Evidence Answer for an Insurer?

Four questions, asked of any release. If an insurer can answer all four quickly, from material produced during the work, it has release evidence. If any answer depends on someone’s memory or a week of assembly, it does not.

The first of those questions is the one a requirements traceability matrix tries to answer, and it shows why a static spreadsheet struggles once the requirements start changing between releases.

What Does an Evidence Chain Look Like for an Insurance Change?

An evidence chain links six things: the source, the requirement, the test journey, the approval, the run and the history of changes to all of them. Walk any single insurance change through those six links and you can see exactly where most firms’ evidence breaks.

Take a common change: a motor insurer adds a loading for drivers under 25 when they are added mid-term.

In most insurers, links one and five exist and links two, four and six live in people’s heads. That is the gap release evidence closes.

Who Owns Release Evidence in an Insurer?

QA produces it, business specialists shape it, risk and compliance use it, internal audit tests it, and a senior technology leader is accountable for it. Ownership works when each group touches the same chain rather than keeping its own copy.

Keeping those business approvals meaningful, rather than a reflex click on the twentieth request of the day, is the design problem behind human-in-the-loop AI testing.

How Does Touchstone Produce Release Evidence?

Touchstone produces release evidence as a by-product of testing, not as a separate exercise before an audit. AI proposes requirements, journeys and tests; a named person approves each one; a deterministic engine executes them; and every decision is kept, versioned and queryable.

The principle is governed autonomy: AI proposes, people govern. Three orchestrator agents do the heavy lifting.

• The Analyst reads your source documents, such as product specifications, underwriting guides, rating guides, policy wordings, backlog tickets and regulatory change summaries, and proposes structured requirements, each citing where it came from.

• The Architect turns approved requirements into test journeys that cross whatever systems the business process crosses: portal, core platform, billing, documents, CRM, payments.

• The Autopilot turns approved journeys into automated tests and runs them on a deterministic engine in your existing CI pipeline.

More than thirty specialised agents sit beneath those three. The AI that reasons is never the system that runs the tests, so results reproduce. Nothing reaches the build without a named person accepting it, and there is no setting that removes that step.

When a source document is revised, Touchstone identifies every affected requirement and test and proposes the change as a reviewable difference. Nothing is updated silently, and the history stays visible.

The outcome for an insurer is simple to describe. When someone asks what shipped, whether it was tested and who approved it, the answer comes from the evidence chain rather than from memory.

To see a complete chain for one release, from source document to approver, take a look at release evidence in Virtuoso QA.

Illustrative Scenario: The Question After a Pricing Incident

This scenario is illustrative and does not describe a specific firm. It shows how the same question plays out with and without release evidence.

A UK motor and home insurer with around 1,500 staff finds in February that a small group of renewal quotes issued through one broker channel were higher than equivalent new business quotes. Compliance asks QA three questions: which tests covered the January rating release, who approved it, and can we rerun those tests against the build that went live?

The difference is not that Touchstone prevented the gap. A missing requirement is a missing requirement. The difference is that the firm can see exactly where it was, prove the fix and show the regulator the whole chain in days rather than weeks.

How Do You Start Building Release Evidence?

Start with one regulated journey, not the whole estate. Pick the journey where a defect would cost the most or draw the most regulatory attention, load its source documents, and let the evidence chain build as the team tests.

Expand once the first chain has survived a real question.

1. Choose the first journey: Renewal pricing, claims payment and policy issuance with documents are the usual candidates.

2. Gather the sources: Product specification, underwriting and rating guides, the relevant wording, open backlog tickets and any regulatory change notes.

3. Approve requirements: Let The Analyst propose requirements and have the business owner approve or correct them.

4. Build cross-system journeys: Follow the money and the data from the first screen to the last downstream system.

5. Run in CI on every build: Evidence that exists only at release time is a snapshot; evidence produced on every build is a history.

6. Agree the evidence pack with audit: Decide with internal audit what a complete chain looks like, then use the Insurance Release Evidence Pack as the template.

7. Extend across the estate: Add the next journey, then the next line of business, reusing the building blocks you already have.

Renewal pricing is the usual first candidate for good reason, and our guide to insurance regression testing shows how to keep pricing, claims and policy journeys covered once the first chain is in place.