Building compliant software in insurance

Ask an insurance software team whether their application meets state data security requirements and the answer usually starts with a state, not a system. "We're licensed in Ohio, so we follow Ohio's version." That answer covers one state correctly. The next question, "and the other 24 states you are licensed in," is the one that finds the gap.

Insurance regulation has a structure that makes this predictable. Unlike a single federal rule, the NAIC Insurance Data Security Model Law is a template that each state legislature adopts on its own schedule, with its own edits. More than 25 states have adopted some version of it as of early 2026 [1]. The core shape repeats: a written information security program, a risk assessment behind it, a named person accountable for it, an incident response plan, and notification to regulators and consumers within a set number of days after a breach is discovered. The details that vary are the ones that matter to an engineer: the notification deadline, the size threshold that triggers it, and which categories of licensee are exempt.

That variation is not a reason to treat compliance as a legal problem with no engineering shape. It is a reason to build the shape once and configure it per state, the same way a tax engine handles fifty different rates rather than shipping fifty different applications.

Why this reframing matters for how software gets built

The model law is, in its operative sections, a specification. "Develop, implement, and maintain a comprehensive written information security program based on ongoing risk assessment" [1] describes a process with an artifact: a program document, produced from a risk assessment, kept current. "Notify the commissioner of insurance ... within 3 business days" [1] (the timing most states adopted) describes a deadline with a trigger: a breach is discovered, and a clock starts. Specifications like these can be tested. A clock either fires within the window or it does not.

Most insurance software treats these requirements the way most regulated software treats requirements in general: read once, implemented approximately, described in a policy document, and left to drift as the application grows around it. Three years after the incident response plan was written, the application added a new integration partner who receives policyholder data, and nobody updated the plan to cover a breach that starts on that partner's side. The policy still reads correctly. The system it describes no longer matches it.

Turning a specification into a check that runs on every change closes that gap, and it is the same argument we make across every regulated industry we build for: see why AI-native development fits regulated work for the general case. Writing several hundred narrow checks, one for each state's notification deadline and each threshold and each exemption, used to be an amount of unglamorous engineering that lost every prioritization meeting to a feature a salesperson was asking for. When generating that code is close to free, the checks stop being a quarter of the engineering budget and become an afternoon of specification work plus a run that repeats forever.

The honest counterweight

None of this holds if the part that makes it work gets skipped, and it is worth saying plainly rather than selling around it.

Generated code is not secure by default. Veracode's spring 2026 testing across more than 150 models and 80 coding tasks found only 55 percent of generations produced secure code, a figure that has stayed roughly flat for two years while syntax correctness climbed above 95 percent [2]. Models became very good at writing code that runs and did not become correspondingly good at writing code that is safe, and in an insurance application the paths where that gap costs the most are exactly the ones a regulator cares about: who can read a policyholder's claim history, what gets logged when they do, and what happens to the data on deletion.

So AI-native development without independent verification produces the same risk faster, not less risk. The checks have to be derived from the obligation before the implementation exists, and graded by something other than the model that wrote the code. Our piece on why you should never let the model grade its own work covers the mechanism, and it is the difference between this being a genuine advantage in insurance software and being a faster way to accumulate the same old risk.

What actually reaches your code

Insurance compliance covers a great deal that never touches an engineer: licensing, rate filings, agent appointments, market conduct. The useful split is the same one that applies across every regulated industry: separate what is satisfied by a person doing something from what only the running system can satisfy, and treat the second set as engineering requirements. Our guide to regulated industry software covers that split in general; this hub applies it to insurance specifically.

The obligations that reach the code cluster in a small number of places. Turning the model law into a specification your team can build against, covered on translating NAIC model law into engineering requirements. The fact that the specific numbers, the notification deadline, the size threshold, the exemptions, differ by state and have to live in configuration rather than in a hardcoded rule, covered on state-by-state data security requirements for insurance software. What the application itself has to do the moment a breach is suspected, covered on incident response and breach notification in your application. For insurers above the Model Audit Rule's premium threshold, what the rule expects of internal control and how software teams fit into that, covered on Model Audit Rule controls for software teams.

Each of those pages translates a rule into what the system has to do and what a check for it looks like.

Building it right, and knowing where you stand

Two further pages cover the practical side of doing this well. Evals as insurance compliance evidence covers why a check suite derived from the model law's requirements is stronger evidence in an exam than a policy document, because it demonstrates behavior rather than intent. Designated security officer and access control covers the model law's requirement to name a person accountable for the security program, and what that means for how access is modeled and enforced in the application itself.

Why teams do not know their own app has a gap

The most useful thing we can tell an insurance team is that a compliance gap in a live application is usually invisible from the inside, for a structural reason rather than a careless one.

An application does what its team designed it to do. When the team reviews it, they review it against that design. The gaps sit in what nobody designed: the state that was never added to the notification configuration because the company was not licensed there when the feature shipped and nobody revisited it when a new license was approved, the claims adjuster export tool that reads customer records in bulk with no audit entry because logging was built around the customer-facing screens, the incident response plan that names a person who left the company fourteen months ago. Each of these is a system working exactly as built. None of them was a decision anyone made on purpose.

This is why a self-review by the same team that built the system usually finds very little. You cannot review against a specification that was never written down, and the whole reason these gaps exist is that it was not. Compliance gaps in insurance software covers the specific patterns we would look for first.

Which obligations apply to your business, and in which states, is a question for counsel rather than for engineers, and nothing in this guide is legal advice. What it does is take the obligations once somebody has scoped them and turn them into things a system can be tested against.

If you are building or modernizing an insurance product, our custom software development service is the place to start, and our eval-driven development guide covers the method behind every check suite we build. If what you need first is to find out where your current application stands, get in touch and we will scope an audit against your real obligations rather than a generic checklist.

Compliance is a property of a running system, and the only honest way to know you have it is to check, on every change, in every state you are licensed to sell in.