Before we've finished explaining what Undwrlyft does, in almost every carrier conversation, the same question surfaces: does our loss history train your model for other carriers?
It's the right question to ask first, and the fact that it's asked consistently tells you something important about how carriers think about insurtech procurement. The underwriting data a carrier accumulates — loss histories, pricing model inputs, appetite parameters, renewal patterns — is among the most commercially sensitive information they hold. It informs their competitive positioning, their rate adequacy, their risk selection strategy. Giving it to a vendor and having it potentially benefit a competitor is not a theoretical concern. It's a procurement blocker.
Why insurance data isolation is different from general enterprise SaaS
Most enterprise SaaS vendors handle multi-tenant data with logical isolation — different organizations' data is stored in shared infrastructure but access-controlled so that one tenant cannot read another's data. That baseline is necessary but not sufficient for insurance use cases, and here's why:
Standard enterprise SaaS models share infrastructure and, crucially, often share model training. If a productivity tool learns from user behavior across all tenants to improve its suggestions, that cross-tenant learning is a feature, not a concern — a carrier's document formatting habits improving the software for everyone is benign. If an underwriting automation system learns from one carrier's loss patterns and pricing decisions to improve its extractions for another carrier in the same risk class, that is information leakage in a form that has material competitive implications.
The specific risk for insurance data isn't that Carrier A can read Carrier B's data in the system. It's that Carrier A's data informs the system's behavior in ways that benefit Carrier B, even if Carrier B never directly accesses Carrier A's data. Model training, feature extraction, normalization calibration, confidence scoring — all of these can carry information across carriers if the isolation model permits it.
What carrier-grade data isolation actually requires
When we designed Undwrlyft's data architecture, the isolation model was a first-principles decision rather than a compliance checkbox. The requirements that emerged:
Dedicated model instances per carrier: The extraction models that learn from a carrier's document corpus — the training that improves loss run extraction accuracy for that carrier's specific set of prior carrier formats and layout patterns — must be carrier-specific. A model trained on Carrier A's document set must not be the same model that processes Carrier B's submissions. This is a stronger requirement than logical data isolation; it requires architectural separation of the training pipeline, not just the data storage.
No cross-carrier feature aggregation: Statistical features derived from one carrier's data — typical loss amounts for a given NAIC class, frequency patterns, attachment point distributions — must not be used to calibrate processing for another carrier's data. This rules out global normalization schemes that would otherwise be a natural efficiency in a multi-tenant system.
Data residency and deletion: Carriers want to know that their data isn't retained beyond the operational purpose, and that they can request deletion with confidence that it actually happens. This requires explicit data retention policies, deletion workflows that cover training data as well as operational data, and audit mechanisms that confirm deletion has occurred.
Encryption key management: Data encrypted with shared keys is logically isolated but not truly isolated if the key management is centralized. Carrier-specific encryption key management — where each carrier's data is encrypted with keys that no other carrier's processing can access — is the standard that serious carriers require.
How the CISO conversation actually goes
The Chief Information Security Officer conversation in carrier procurement is distinct from the business case conversation with the CUO. The CISO is not evaluating whether the platform improves underwriting throughput — that's the business team's evaluation. The CISO is evaluating whether the vendor introduces acceptable risk into the carrier's data environment.
The standard framework for these conversations in 2025 is built around SOC 2 Type II. A SOC 2 Type II report demonstrates that a service organization's controls have been tested over a period of time — typically six to twelve months — and found to be operating effectively. The trust service criteria (Security, Availability, Confidentiality, Processing Integrity, and optionally Privacy) map to the concerns a carrier CISO has about a vendor handling underwriting data.
We're not saying SOC 2 Type II is the complete answer to the data isolation question — it's a necessary condition, not a sufficient one. The SOC 2 scope covers the general security controls, but the carrier-specific data isolation architecture we've described goes beyond what SOC 2 criteria require as a baseline. The CISO will want to understand the technical architecture, not just the controls attestation.
Third-party vendor sub-processors
A specific area of CISO scrutiny in insurtech procurement is the sub-processor chain — the cloud infrastructure providers, OCR APIs, AI model providers, and other third parties that a vendor's system depends on, and to which carrier data may flow. A vendor's SOC 2 report covers the vendor's own environment, but if the vendor's extraction pipeline sends document content to a third-party AI API, that API provider is a sub-processor handling carrier data.
The sub-processor question has become more pointed as large language model APIs from major technology providers have become common in enterprise software. A carrier CISO will ask: does your system send our submission PDFs or extracted loss data to any third-party AI API? If yes, under what data use terms? Does that API provider's standard contract permit them to use submitted data for model training?
This is not hypothetical. Several major AI API providers have standard contract terms that permit using submitted data for model improvement unless the customer has opted out or purchased a specific enterprise tier that contractually prohibits it. For a carrier submitting its proprietary loss runs and pricing model inputs to a vendor's platform, the sub-processor data use terms are material.
The procurement process for carriers that get this right
Carriers that have developed mature insurtech procurement processes tend to run parallel tracks: the business evaluation (does the product actually work, does it improve our underwriting operations, what's the ROI case) and the technical/security evaluation (data isolation architecture, SOC 2 posture, sub-processor chain, data retention and deletion). The business track and the security track have to both reach positive conclusions before procurement can advance.
The carriers where procurement moves fastest are those that have clear security requirements established before they start the evaluation — a written set of technical criteria that vendors must meet, rather than starting from scratch in each vendor conversation. For carriers without an established vendor security framework, the security evaluation often takes longer than the business evaluation, and the delay costs both parties time.
The data isolation question is a feature, not an obstacle. A vendor that can answer it clearly and completely — with architectural specifics, not just policy language — is a vendor that has designed its system for the carrier environment rather than adapted a general enterprise SaaS model to insurance. That distinction matters for every conversation beyond the first one.
