The Right-to-Erasure Problem: Deleting One Customer Across Twelve Systems

A customer emails and asks you to delete everything you hold about them. Under GDPR, the UK Data Protection Act, or CCPA, you have a legal obligation and a clock ticking. Simple request. Then you go looking for "everything," and you discover the uncomfortable truth about your own company: you have no idea where all of it is. The right-to-erasure request isn't really a privacy problem. It's a data-architecture problem wearing a privacy costume, and it exposes exactly how fragmented an insurer's data really is.

One customer, twelve systems, zero map

A single policyholder's footprint inside a mid-sized insurer typically spans: the policy admin system, the claims system, the billing platform, the CRM, the document store full of scanned PDFs, the data warehouse, three or four analytics marts, the email archive, the contact-centre call recordings, the fraud database, a couple of vendor platforms, and — the one everyone forgets — the backups. To them it's one relationship. To your estate it's fifteen disconnected records, several of which don't share a common identifier.

That last point is the killer. If the claims system knows the customer by a claim number, billing by an account ID, and the CRM by an email that's since changed, then "delete this person everywhere" has no single query that can find them. You cannot erase what you cannot locate, and most insurers cannot reliably locate a customer across their own estate.

Delete is harder than it sounds — on purpose

Even once you've found every record, deletion runs headlong into other obligations that also carry legal weight:

  • Retention laws. You're often required to keep certain claims and financial records for years. "Erase everything" collides with "retain this for seven years," and you have to resolve the conflict correctly, per field, not per customer.
  • Active contracts and claims. You can't erase someone mid-claim or mid-policy. The right isn't absolute; it's balanced against legitimate processing.
  • Referential integrity. Hard-deleting a customer row can orphan claims, break financial reconciliations, and corrupt the very audit trails a regulator will later ask for.
  • Analytics and model training. Their data may already be baked into aggregate tables and training sets. Do those need to be scrubbed too? Frequently, yes — and almost nobody has a plan for it.

The backup problem nobody wants to discuss

You deleted the customer from every production system. Congratulations. Their data still sits in last night's backup, and the one from the night before, going back months. Technically it's still personal data you're holding. The pragmatic, defensible answer is a documented policy: production is scrubbed immediately, backups age out on their normal cycle and are not restored selectively to resurrect erased records. But you have to have decided that and written it down before a regulator asks, not improvise it under pressure.

Why this is a foundation problem, not a compliance project

Here's the reframe that matters. Every capability that makes erasure possible is the same capability that makes good insurance AI possible:

  • A reliable way to resolve one customer across all systems — that's entity resolution, the same thing your customer-360 and fraud efforts need.
  • Knowing what data lives where and what it means — that's a data catalog and lineage, the same thing your regulators and your ML teams need.
  • Field-level rules about retention and consent — that's data governance, the same thing that keeps your models compliant.

An insurer that can cleanly honour a right-to-erasure request is, almost by definition, an insurer whose data foundation is in order. One that can't has just been handed a precise, legally-motivated diagnosis of its fragmentation.

What "good" looks like

The mature setup treats erasure as a routine, mostly-automated workflow: a request comes in, an entity-resolution layer finds every record for that person across the estate, a governance layer decides field-by-field what must be deleted versus legally retained, the deletions execute with referential integrity preserved, and the whole thing is logged as evidence you complied. No heroics, no six-week scramble, no praying you didn't miss a system.

Getting to that point is unglamorous data-foundation work — identity resolution, cataloguing, governance rules — and it's exactly the work we do with insurers at IntelliBooks. The upside is that you don't just satisfy the privacy regulator; you build the same plumbing every other data initiative in the company has been quietly waiting for.

Treat the first erasure request as a fire drill that reveals the map you never had. Then build the map, because the requests aren't going to stop.

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

Straight-Through Processing: From 10% to 90%

Straight-through processing is the number every insurance executive quotes and almost nobody achieves. The industry benchmark has moved from 10–15% to 70–90% at the carriers who've cracked it. That's not a marginal efficiency gain — it's a different cost structure. So why is your STP rate still stuck in the teens? Because STP gets treated as a workflow project. It isn't. It's a data problem wearing a workflow costume. What STP actually requires Straight-through means a quote, policy, or claim goes from submission to completion with zero human touches . For that to happen, every decision point in the chain has to be answerable automatically. Every single one. A chain of nine automated steps and one manual check isn't 90% straight-through — it's 0%. One human touch and the whole thing is a manual process with extra steps. That's the bar. And it means the constraint isn't the workflow engine — it's whether the data needed at each decisio...
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