Read the policy before the incident

There is a simple idea I keep coming back to: let an organisation bring its insurance policy into the design of its evidence system.

The policy is already a description of a commercial relationship under particular conditions. Yet the systems doing the work may know very little about the records, notifications or approvals that could matter if something goes wrong. We then ask people to assemble the connection during an incident, when they are rarely short of other entertainment.

I would like to explore the reverse order. With permission, the organisation supplies the relevant policy documents to a controlled system. The system proposes an evidence plan grounded in specific clauses. A qualified person reviews that interpretation before it changes collection or response procedures.

It would not guarantee a payout. Coverage still depends on the policy, the circumstances and the applicable law. What interests me is the opportunity to discover an awkward question while there is still time to do something useful about it.

The useful first step would be surprisingly ordinary: identify the correct documents. A policy wording alone may be incomplete without its schedule and endorsements. The system should show what it has, which version applies and what remains missing. A confident summary of the wrong year's policy would be an efficient way to begin badly.

The policy could then become the start of a practical conversation. A team might discover that it cannot reconstruct when an account gained access, or that nobody knows who should contact the insurer. Those are fixable problems on a quiet Tuesday. The system could bring the relevant wording to the broker or adviser, with a precise question rather than a general request for reassurance.

Even finding the proper recipient matters. Lloyd's claims guidance explains that claims notification details should be found in the policy and that Lloyd's itself does not process policyholder claims. A system that sends a beautifully prepared incident report to the wrong institution has completed the least useful part of the task.

The resulting evidence plan might specify records of access changes, approvals, detection times and response actions. It might also identify information already collected elsewhere, avoiding another store of duplicated sensitive material. Each requirement should have an owner, a purpose and an agreed retention approach.

This would need careful handling during an incident. Collecting more evidence must not silently delay containment or required notification. Some response decisions may require insurer consent under the particular policy. Lloyd's market guidance on ransomware incidents discusses consent, engagement and regulatory considerations, while expressly leaving coverage determination outside its scope. It is a useful illustration of why a generic “incident handled” status conceals several distinct responsibilities.

The system should also resist collecting everything just in case. The ICO's data-minimisation guidance links collection to a defined purpose and the information actually needed. An insurance-related purpose deserves the same discipline as any other. Policy documents themselves can contain confidential details, so their storage, processing and disclosure need boundaries too.

The responsibility runs both ways: within its applicable UK scope, FCA claims-handling rules require fair and prompt handling, reasonable guidance and protection against unreasonable rejection. Better preparation should make the conversation clearer, without suggesting that every missing log settles a claim against the policyholder.

The practical benefit is less uncertainty on both sides. A policyholder can explain its controls with something more useful than a confident questionnaire. A broker can identify gaps while changes are still manageable. During a claim, people can locate relevant records without reconstructing the entire business from memory. The relationship becomes better informed before anyone needs to test it under pressure.

I think the most useful version would feel quite modest. It would surface a few questions, help resolve them and leave the organisation better prepared. The policy could come out of the drawer before the incident. That alone would be a worthwhile change.