Who Owns the Data? The Governance Question Nobody Answers

Every insurer's data problems eventually trace back to a question nobody wants to answer: who actually owns the data?

Not "who stores it" — that's IT. Ownership in the sense that matters: who decides what "active policy" means, who is accountable when the roof-age field is 30% blank, who signs off that this data is fit to feed an AI model. At most insurers the honest answer is "no one," and that answer is the root cause of problems everyone else treats as technical.

Why "no one owns it" is the default

Insurance data grew up inside product and function silos. The auto team owned the auto system and its data — for auto's purposes. Claims owned claims data for claims' purposes. Nobody owned the data as a shared asset, because until recently it was never used as one.

Then AI and analytics arrived, wanting to use everyone's data together, and discovered there was no owner of "together." The auto team's definition of a customer differs from billing's. The claims team's data quality is good enough for claims and useless for underwriting. And when a cross-functional model needs all of it to be consistent, there's no one with the authority to make it so.

This is why data-quality initiatives stall, why definitions never get agreed, and why every AI project spends its first months in meetings rather than models. The technical work is waiting on an ownership decision nobody has the mandate to make.

The two failure modes

Insurers that recognise the problem usually over-correct into one of two failures.

Failure one: IT owns the data. It seems logical — IT runs the systems. But IT doesn't know what the data means or what it's for. They can tell you the field is 30% blank; they can't tell you whether that matters, because that's a business judgment. Data owned by IT gets managed as infrastructure, not as an asset with a purpose.

Failure two: a central data team owns everything. A shiny new Chief Data Office is created and made accountable for all data. It becomes a bottleneck and a scapegoat — responsible for quality it can't control, because the data is produced by business processes it doesn't run. You can't own the quality of data you don't create.

Both fail for the same reason: they separate accountability for the data from the people who actually produce and understand it.

What actually works: federated ownership

The model that works keeps ownership with the business, but makes it explicit and accountable:

1. Domain data owners, in the business. The underwriting leader owns underwriting data. The claims leader owns claims data. Not IT, not a central team — the person whose function produces and understands it. They're accountable for its definitions, quality, and fitness.

2. A central team that enables, not owns. The data platform team provides the tools, standards, and infrastructure — the paved road — but doesn't own the domains' data. They make it easy for owners to do the right thing; they don't do it for them.

3. Explicit definitions, owned by someone. "Active policy" has one definition, and a named person owns it. Disagreements get escalated to a forum with the authority to decide — because someone senior has to end the argument, and "we'll each keep our own definition" is how you got here.

4. Data treated as a product. Each domain's data has an owner, a quality standard, documentation, and consumers it's accountable to — like a product, not an exhaust stream.

Why this is a leadership problem, not a tech one

Notice there's almost no technology in the above. That's the point. The hardest part of fixing insurance data isn't pipelines or platforms — those are tractable. It's getting the organisation to decide who's accountable for what, and to give those people the mandate to enforce it.

This is why data problems outlast every tool an insurer buys. You can migrate to the best lakehouse in the world, and if no one owns the meaning and quality of what goes into it, you've built a beautiful, well-governed home for the same ambiguous, disputed data.

The uncomfortable ask

If you're trying to fix data quality, unify customer identity, or get an AI programme moving, and it keeps stalling, look past the technology. Ask: for the data this depends on, is there a named owner in the business with the mandate and accountability to make decisions about it?

If not, that's the actual blocker, and no platform will move it. Establishing ownership is unglamorous, political, and has no launch event — and it's the prerequisite that determines whether everything technical you build on top of it works or drowns in ambiguity.

Someone has to own the data. Deciding who is a leadership act, not an IT ticket — and it's the one that unblocks the rest.

We help insurers stand up the data platforms and operating models — including federated ownership — that make everything downstream possible. More at IntelliBooks.

Comments

Post a Comment

Popular posts from this blog

Why Insurance Fraud Rings Are a Graph Problem (And Your SQL Database Can't See Them)

Your fraud team is good at catching individuals. A claimant whose story shifts, a receipt that looks altered, someone who files a bit too often. That's what the rules were built for, and they work. They're nearly blind to organised fraud — and organised fraud is where the money goes. The reason isn't that your team lacks skill or your rules lack sophistication. It's that you're asking a question your database structurally cannot answer. What a fraud ring actually looks like A ring isn't one bad claimant. It's a network: a handful of claimants, a couple of "witnesses", a repair shop, a medical clinic, a few bank accounts, some phone numbers, and a device or two — recombined across dozens of claims over months. Take any single claim from that ring and it looks fine. The claimant has no history. The damage is plausible. The repair estimate is in range. Nothing trips a rule, because the rule is examining one claim in isolation, and in isolati...
Read more

Claims Leakage: The Quiet Loss AI Can Close

Claims leakage is the money your company pays out that it didn't have to. Not fraud — leakage. The extra amount on legitimate claims that got overpaid because someone missed something, applied the wrong rule, or lacked the information to know better. Industry estimates put it at 3–10% of claims spend. For a mid-size insurer that's a rounding error you could retire. And almost nobody manages it directly, because it's nearly invisible — every individual leaked rupee looks like a normal payment. Why leakage is so hard to see Fraud has a villain. Leakage doesn't. It's the accumulation of small, defensible, individually-reasonable decisions: An adjuster settled at the reserve figure because they were busy, and the reserve was set high. A repair was authorised at shop rates when a network rate applied. A subrogation opportunity was never flagged, so recovery never happened. A policy limit or deductible was applied wrongly because the coverage detail was buried...
Read more

The Subrogation Money Insurers Leave on the Table

Subrogation is the least glamorous word in insurance and one of the most profitable. It's the process of recovering money from the party actually responsible for a loss, after you've paid your customer. Done well, it flows straight to the bottom line — recovered money is nearly pure margin. Most insurers leave a lot of it on the table. Not because they don't try, but because the opportunities are identified too late, by the wrong people, from incomplete information. It's a data problem, and it's an unusually clear one. Why subrogation is a timing game you're losing Recovery potential decays fast. The evidence that establishes another party's liability — the scene, the witnesses, the vehicle, the maintenance records, the CCTV — degrades or disappears within days. The other party's insurer gets less cooperative once they've closed their own file. So the single biggest lever in subrogation is identifying the opportunity early , ideally at first ...
Read more