Multi-Tenant vs Dedicated Environments for Insurance Software

A multi-tenant environment runs many customers on one shared instance of the software. Everyone uses the same code base and the same underlying infrastructure, and each customer's data is separated logically, by the application, rather than physically.

A dedicated environment gives one carrier its own instance: its own database, its own compute, its own agents, and its own security boundary. Nothing is shared with another customer.

The practical differences:

• Database: Shared, with your rows separated by software, Your own
• Compute: Shared with other customers, Your own
• Security boundary: The vendor's, around everyone, Yours, around you
• Code base: One version for all customers, Configured to your business rules
• Upgrades: On the vendor's schedule, for everyone at once, On yours
• Who else is affected by an incident: Potentially every customer, You, and only you

Multi-tenant is how most SaaS software is built, and for a lot of businesses it's the right trade. The question for a carrier is whether the trade is right when the data is policyholder records and the regulator expects you to know exactly where they are.

It means the vendor runs one big system and rents you a slice of it.

The advantages are real. It's cheaper for the vendor to operate, which usually means cheaper for you.

There's one version of the software, so every customer gets the same upgrade at the same time. Support is simpler because every customer looks the same.

The trade-offs are also real, and they tend to be the ones a sales conversation skips:

• A shared database. Your data and another carrier's data sit in the same tables, separated by a tenant ID. The separation is a rule in the code, and rules in code can have bugs.
• A shared code base. You can't have your rating logic in the core, because everyone shares the core. Customization has to live in a layer on top, or not at all.
• A shared upgrade schedule. When the vendor ships a change, you get it, whether your quarter-end can absorb it or not.

Related: What Is a Parallel Run? The Safest Way to Go Live on a New Insurance Platform

• Shared performance. Another tenant's heavy month is your slow month.
• A shared blast radius. A breach or an outage on the shared layer reaches every customer on it.

None of that makes multi-tenant wrong. It makes it a specific set of decisions that someone else has already made on your behalf.

Because the cost of getting it wrong is higher, and the regulator will ask who was responsible.

IBM's 2025 Cost of a Data Breach report, based on research by the Ponemon Institute across 600 breached organizations, put the global average cost of a breach at $4.44 million. In the United States the figure was $10.22 million, an all-time high for any region. Those numbers are averages across industries.

A carrier's breach involves policyholder identities, claims histories and financial details. It lands in a regulatory environment with a simple question: where was the data, and who could reach it?

In a multi-tenant environment, the honest answer is that the data was in a shared system, protected by a separation the vendor controls. Your security boundary is somebody else's operational decision.

Our own view, in the checklist we give carriers evaluating vendors, is blunt: if the vendor is sharing any of your resources in a multi-tenant environment, security is compromised. Period.

That's a strong statement and we mean it for one reason. A carrier can't delegate accountability for policyholder data, so it shouldn't delegate the boundary either.

That thinking is part of why Force exists at all, which we explain in why we built Force.

It means every carrier on Force gets isolated infrastructure. In our own words: your own database, your own agents, your own intelligence layer. Data isolated in your security boundary. Configured for your business rules.

What that gives you day to day:

• Your own database. Not a tenant ID in a shared table. A database that holds your data and nobody else's.
• Your own agents. The AI agents running your workflows run inside your environment, on your data, under your rules.
• Your own security boundary. An incident somewhere else is somewhere else.
• Your own configuration. Rating logic, workflows, and approval thresholds are set for your business, not constrained by what every other customer needs.
• Your own access model. Role-based access is granular, groups can be created and edited in real time, and it covers both human users and AI agents.
• Individually managed. Custom-tailored and individually managed environments, with 99.9% uptime and industry-leading security.

This is also the environment our agents run in from day one, on top of whatever core system you have now. It's the on-ramp to a new core, not a layer bolted onto the old one. That's why we describe modernization as a sequence of small steps rather than one program, in how to modernize an insurance core system without a three-year migration.

We never train on your data. The intelligence in your environment sharpens with every interaction, but it accumulates in your own configurations and retrieval. It doesn't leave your boundary to improve a model that another carrier then benefits from.

AI models are interchangeable. The intelligence layer isn't, and yours stays yours.

The reason to be specific about this is that AI is now the most common way data leaves a boundary without anyone deciding it should. IBM's 2025 report found that 20% of the organizations it studied had suffered a breach involving shadow AI, meaning AI tools used without employer approval or oversight. Where shadow AI was widespread, those breaches cost $670,000 more on average.

A dedicated environment is the structural answer. The agents your teams use live inside your boundary, on your data.

Their access is governed by the same role-based controls as your people. So there's no reason for anyone to paste a claims file into a tool you don't control.

Traditionally, yes on both counts. That's the honest reason multi-tenant became the default.

Running a separate instance per customer used to mean separate servers, separate upgrade projects and separate retesting for every release. The cost was real and so was the lag, which is why "dedicated" often came to mean "a version behind."

Whether that's still true depends on the architecture underneath. A platform built as true microservices, with independent services and zero-downtime updates, can run dedicated environments without the old penalty, because each service updates on its own without a coordinated release. A monolith wearing a microservices label can't, and most vendors claiming microservices are running exactly that.

Force is built as true microservices, with zero-downtime updates. That's what lets every carrier run in a dedicated environment without the old cost and lag.

So the question isn't "dedicated or multi-tenant?" on its own. It's "dedicated, on what?" Ask the vendor what happened at their last major release. A maintenance window and a customer-wide retest means a monolith, whatever the slide says.

Ask the question from our vendor checklist, and listen to the shape of the answer.

• Regarding security, is our compute environment and infrastructure physically isolated from other clients?: "Pretty much, your policyholder data is isolated.", Data isolation is not environment isolation. If any resource is shared, the boundary is shared. You want a dedicated cloud environment with no shared data or code bases.

Then go one level down:

1. Is the database ours, or is it a tenant ID in yours?
2. Is the code base configured to us, or shared with every customer?
3. Who decides when we upgrade?
4. Can our team create and change permission groups in real time, at the database level?

Related: Premium Leakage: How Disconnected Systems Quietly Cost Carriers Money

1. Do the same access controls apply to AI agents as to people?

Ideally you want an architecture that maximizes both security and access. That means a dedicated environment local to your business. It also means a highly modular data layer, so user access can be customized at the database level and permissions changed in real time.

Vendors who have that will answer the five questions quickly. Vendors who don't will answer a different question.

Two things a dedicated environment changes that are easy to miss.

Migrating in is cleaner, because there's no shared schema to fit your data into. The environment is built around your operational logic, mapped before a single record moves. That happens in the first four weeks of every implementation, which we set out in how Force implements: five phases, one clear path.

Getting data out is the part to test before you sign. Our checklist puts the question as: can we easily extract and use our data for any advanced analytics purpose, independent of your built-in tools?

The answer you'll hear is "sure, you can download it all." Exactly how available the downloads are is the key question. If you must click through screen after screen to extract your own data, it isn't really available, usable, and uncorrupted.

Your data stays yours. That has to be true on the way out as well as the way in.

• A multi-tenant environment runs many carriers on shared infrastructure, code, and often a shared database, with data separated by software rules. A dedicated environment gives one carrier its own database, compute and security boundary.
• Data isolation and environment isolation aren't the same thing. When a vendor says your data is isolated, ask whether your environment is, as well.
• IBM's 2025 report puts the average US data breach at $10.22 million, and found 20% of breached organizations had an incident involving shadow AI.
• A dedicated environment means your own database, your own agents and your own boundary, with access controls that govern AI agents and people alike, and no training on your data.
• Whether a dedicated environment carries the old cost and upgrade penalty depends on whether the platform underneath is genuinely built as microservices.

What is multi-tenant insurance software?

It's software where many insurance companies share the same running instance, infrastructure and code base, with each company's data separated logically by the application. It's cheaper to operate and simpler to upgrade, but the security boundary, the upgrade schedule and the database are shared with every other customer on the platform.

Related: No-Code Policy Configuration: Launch Insurance Products Without Engineers

What is a dedicated environment for insurance software?

It's an instance of the platform that serves one carrier only: its own database, its own compute, its own agents, and its own security boundary. Configuration, access controls, and upgrade timing belong to that carrier. Nothing is shared with another customer.

Is multi-tenant software secure enough for policyholder data?

Many carriers run on it. Our view is that a carrier can't delegate accountability for policyholder data, so it shouldn't delegate the boundary either. If any of your resources are shared, your security depends on separation rules that the vendor controls and that you can't inspect.

Does Force train AI models on carrier data?

No. We never train on your data. The intelligence accumulates in your own configurations and retrieval inside your dedicated environment. Models are interchangeable; the intelligence layer stays yours.

Multi-tenant software is a reasonable default for most businesses. It's a set of decisions about your data that someone else has made in advance.

For a carrier, those decisions are the ones the regulator will ask you about. “It was in the vendor's shared system" isn't an answer that ends the conversation.

A dedicated environment puts the database, the boundary, and the agents inside a line you own. Whether it costs you the old penalty depends on what it's built on.

Ask where the data is. Then ask where the boundary is. If the answers are different, keep asking.

Every carrier on Force runs in a dedicated environment from day one, with the agents inside it.

Book a demo of Force and we'll show you what your boundary looks like.