Your Test Environments Are Running on Real Customer Data

Ask where the data in your development and test environments came from and the answer is very often a copy of production, taken some time ago, by someone who needed realistic data to test against. It's an entirely understandable shortcut — synthetic data is hard, and defects hide in the messiness of real records. It also means real policyholders' names, addresses, claim details and payment information are sitting in environments with weaker access control, looser monitoring, and a much longer list of people who can reach them.

Why it keeps happening

Testing insurance systems genuinely needs realistic data. Rating engines, matching logic, document generation and migration scripts all behave differently on the long tail of odd real-world records, and clean synthetic data hides exactly the defects you most want to find. So teams copy production because it works, and the copy quietly becomes permanent — refreshed occasionally, never inventoried, and rarely covered by the same controls as the system it came from.

Where it breaks down

  • Weaker controls. Non-production environments typically have broader access and lighter monitoring than the system of record.
  • Untracked copies. Nobody maintains a list of which environments hold personal data, so the exposure isn't even measurable.
  • Privacy requests miss it. An erasure request handled in production leaves copies of that customer alive in three test databases.
  • Masking is partial. Where masking exists it often covers obvious fields and leaves free-text notes, documents and attachments untouched.

Why it's a data-foundation problem

The answer isn't to ban realistic test data — teams will find a way regardless, and testing quality matters. It's to make safe test data a managed capability: know which environments hold what, mask or synthesise consistently including free text, and make provisioning a governed, repeatable process rather than an ad-hoc copy. Done well, teams get data that behaves like production without carrying production's risk, and privacy obligations extend across the estate instead of stopping at the system of record.

What good looks like

  1. An inventory of which non-production environments hold personal data.
  2. Consistent masking or synthesis that covers free text, documents and attachments, not just obvious fields.
  3. Referential integrity preserved so masked data still exercises joins and matching logic realistically.
  4. Governed provisioning — a repeatable process, not a copy someone took once and nobody tracked.

Test environments are where insurers quietly hold the most personal data with the least protection, largely by accident. Making test data both realistic and safe is exactly the kind of work we do with insurers at IntelliBooks.

Your production controls are only as strong as the copies of production you forgot you made.

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