How Long Should You Keep Insurance Data? Nobody Knows, So You Keep Everything

Ask an insurer what its data retention policy is and you'll usually be handed a document. Ask what actually happens to a policy record fifteen years after the policy lapsed and the answer is almost always the same: it's still there. Insurance has genuine reasons to keep data for a long time — long-tail liabilities, latent claims, regulatory and legal obligations that run for years. But "we might need it" has quietly become "we delete nothing," and that default carries costs and risks nobody signed off on.

Why keeping everything feels safe and isn't

Deleting data feels risky: if a claim surfaces in twenty years, you want the file. So the cautious choice is always to retain, and since nobody is accountable for the cost of retention, the cautious choice always wins. But data you keep is data you must secure, must include in a breach if one happens, must search when a customer exercises a privacy right, and must migrate every time you change platforms. Indefinite retention isn't a neutral default — it's an accumulating liability that grows quietly in the background.

Where it breaks down

  • Policy on paper, not in systems. The retention schedule exists as a document; no system enforces it.
  • No basis per data type. Everything is kept for the longest period any category might need, because nobody differentiated.
  • Copies escape the policy. Even where the system of record expires data, extracts, backups and test copies don't.
  • Deletion is unprovable. When something is deleted, there's no evidence trail to demonstrate it to a regulator.

Why it's a data-foundation problem

Retention only works if it's enforced by systems rather than described in a document, and enforcement needs a foundation: knowing what data you hold, where it lives including copies, what legal basis and period applies to each category, and a mechanism that actually expires it with an auditable record. That's the same data-mapping and governance capability that makes privacy requests answerable — which is why insurers who fix one usually find they've fixed a good part of the other.

What good looks like

  1. Retention defined per data category with a stated legal basis, not one blanket maximum.
  2. Enforced by systems, so expiry happens automatically rather than aspirationally.
  3. Copies covered — extracts, backups and non-production environments included in the schedule.
  4. Auditable deletion so you can evidence what was removed and when.

Keeping everything forever looks like caution and behaves like an accumulating risk: more to secure, more to breach, more to search, more to migrate. Building retention that's actually enforced is exactly the kind of work we do with insurers at IntelliBooks.

The safest data is the data you no longer hold and no longer need. That only helps if you can prove it's gone.

Comments

Post a Comment

Popular posts from this blog

Why Your Insurance Data Warehouse Didn't Fix Anything

You built the data warehouse. It took eighteen months and cost more than planned. Policy data, claims data, billing — it's all in there. The project was declared a success and everyone moved on. And yet: underwriting still can't see the whole customer. The AI initiative is still stalled. Someone still asks for a report and waits three weeks. Nobody says it out loud, but the question hangs there — what exactly did we buy? You're not alone, and it isn't because you built it badly. It's because a warehouse solves a problem you didn't have. The problem a warehouse solves Warehouses solve location . Before: your data was in eight systems. After: it's in one place. That's genuinely valuable — you can run a query across policy and claims without begging two teams for extracts. But notice what that fixes: it fixes where the data is . It doesn't touch what the data means , whether it's trustworthy, or whether the records refer to who you think t...
Read more

Embedded Insurance: Why the API Is the Easy Part

Embedded insurance is the idea that coverage should be offered at the moment of need, inside someone else's product — travel insurance at checkout, device protection when you buy the phone, cover for the rental car in the booking flow. It's one of the fastest-growing distribution models in the industry, and every insurer has a strategy slide about it. Most of those strategies underestimate the same thing, and it isn't the partnerships or the product. It's the data plumbing. Everyone assumes the API is the hard part. The API is the easy part. What embedded insurance really demands The promise of embedded is speed and invisibility: a customer buys a flight and, in the same breath, is offered exactly the right travel cover at exactly the right price, and accepts with one tap. No forms, no friction. Deliver that and you've won. But "exactly the right cover at exactly the right price in one tap" makes brutal demands on your back end: You must price i...
Read more

Insurance Knowledge Graphs: The Foundation AI Needs Before It Can Think

Every insurer wants enterprise AI. Few realise they're missing something much more fundamental. Knowledge. Not data. Knowledge. Insurance companies already possess enormous amounts of information. Policy systems contain customer records. Claims platforms hold loss histories. CRM systems track interactions. Document repositories store underwriting reports. Data warehouses consolidate analytics. Yet AI still struggles to answer surprisingly simple questions. Not because the information doesn't exist. Because the relationships between that information remain invisible. Data tells you what exists A customer database tells you who someone is. A policy database tells you what they bought. A claims system tells you what happened. An accounting platform tells you what was paid. Each system is internally consistent. Together they rarely behave like a connected enterprise. Humans mentally assemble those relationships every day. Computers usually canno...
Read more