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 structure 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 structure. It is a reason to build the structure once and configure it per state, the same way a tax engine handles fifty different rates rather than releasing fifty different applications.

Why this change of view 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 time limit starts. Specifications like these can be tested. A notification is either sent within the time limit or it is 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 fall out of date as the application grows. 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 fixes that mismatch, 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 was always ranked below a feature a salesperson was asking for. When generating that code costs almost nothing, 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 limitation

None of this works if the key part gets skipped, and it is worth saying plainly rather than hiding it in a sales pitch.

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 rose 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 applies to your code

Insurance compliance covers a great deal that never involves 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 apply to the code are grouped 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 be stored 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 checking what you have

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 to the team that built it, 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 are in what nobody designed: the state that was never added to the notification configuration because the company was not licensed there when the feature was released 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.

How a multi-state compliance matrix actually gets built

The phrase "state-by-state compliance" tends to make a team picture a policy document with fifty sections, one per state, read by whoever prepares for an exam. That version exists in most companies already, and it is not what closes the gap this guide is about, because a document read once a year cannot answer whether the running application currently agrees with it.

The version that closes the gap is a matrix stored as data, not as prose. One row per state the company is licensed in, one column per requirement that varies by state under the NAIC Insurance Data Security Model Law: the number of business days to notify the commissioner, the number of days to notify affected consumers, the policyholder count that triggers a notification duty if the state sets one, and any exemption that applies to the company's category of license in that state. State-by-state data security requirements for insurance software covers the structure of that table in detail.

Building the matrix the first time is research work, not engineering work. Someone, usually counsel or a compliance analyst rather than an engineer, has to read each state's actual adopted statute, since a state can adopt the model law with amendments that change a number or add an exemption the template did not have. The output of that research is a fact, not code: "Ohio requires notification to the commissioner within 3 business days of determination, with no size exemption for our license category." The engineering task is to store that fact where the application can read it and to write a check that fails if the fact is missing for a state the company currently holds a license in.

Keeping the matrix current after that first build is the part that usually breaks. Two events cause a matrix entry to go stale: the company gets licensed in a new state, or a state that is already covered amends its own adopted version of the law. Neither event naturally reaches the person or the system responsible for the matrix. A new license is a sales and legal milestone, tracked in whatever system handles licensing, and nothing about approving a license automatically tells engineering there is a new row to add. A state amendment is even quieter: it happens in a state capitol, and the only businesses that reliably notice right away are the ones paying a legal or compliance service to watch for it.

The practical fix on both counts is the same: connect the event that changes the underlying fact to a required update of the matrix, rather than trusting someone to remember. A new license approval should be a checklist item that includes "add or confirm the state's row in the notification matrix," reviewed as part of the same process that activates sales in that state. A periodic reminder, tied to a defined interval rather than left open-ended, should prompt whoever tracks legal changes to confirm each existing row is still accurate. Neither of these is a difficult engineering problem. Both are easy to skip precisely because skipping them causes no visible failure until an incident happens in the state nobody updated.

What changes on the day a carrier gets licensed in a new state

It is worth walking through what actually has to happen, in order, the day a company's license in a new state becomes active, because most of the failure modes in this guide trace back to one of these steps being skipped.

The notification matrix needs a new row, with the correct notification deadline, threshold, and exemption status for that state, entered by whoever is responsible for tracking the state's adopted version of the model law, not guessed at by an engineer under a deadline. This is the step covered in detail on state-by-state data security requirements for insurance software.

The check that compares licensed states against configured states needs to see the new license. If the list of licensed states lives in a licensing system and the notification matrix lives in application configuration, the two have to be compared automatically, or the comparison depends on someone remembering to run it. A new license with no matching configuration row is exactly the gap an automated comparison exists to catch, and it should fail loudly rather than pass silently.

Consent language and privacy disclosures shown to policyholders in that state may need a review, since some states impose disclosure requirements beyond the security program itself. This is a smaller, state-specific detail, and it is the kind of detail that only surfaces if someone is looking for it deliberately rather than assuming the existing disclosure text already covers every jurisdiction.

The incident response rehearsal needs to include the new state in its next run. A rehearsal that simulates a breach affecting policyholders in the states the company held licenses in at launch will not exercise the new state's deadline until someone deliberately adds it to the simulation, and the first real test of a new state's notification path should not be an actual breach.

None of these four steps requires new technology. Each one requires a defined owner and a defined trigger, so that a new license is a known sequence of updates rather than an event that only touches sales and legal while the application quietly falls out of step with what it now needs to do.

What a checklist misses that an enforced system does not

There is a real difference between a compliance checklist and a system that enforces the rule it describes, and the difference is not effort. Many insurance companies have thorough checklists. The gap is that a checklist is read by a person, on a schedule the person controls, and it says nothing about what happens between readings.

A checklist item that says "verify the notification matrix covers every licensed state" is correct advice. It is checked when someone remembers to check it, which in practice is often once a year, before an exam, when the incentive to look closely is at its highest and the time available is at its lowest. A new state added in March and an amendment passed in July can both sit unnoticed until the following February, when the annual review finally reaches that line item.

An enforced system asks the same question every time the application deploys, or on a nightly schedule, rather than once a year. The check either passes, meaning the matrix currently matches the license list, or it fails, meaning someone finds out about the gap in hours rather than in months, and finds out from a build failure rather than from a regulator's letter. The underlying question, does the configuration match the licensed states, is identical in both cases. What differs is how quickly a true answer of "no" reaches a person who can act on it.

This is not an argument that checklists are worthless. A checklist is still the right tool for anything that genuinely requires human judgment, such as deciding whether a state's amended exemption applies to the company's specific license category, which is a legal question no check can answer on its own. The distinction worth holding onto is which category a given compliance task falls into: a factual comparison between two lists, which a system can run continuously and cheaply, or a judgment call that needs a person to look at specifics, which a checklist correctly routes to that person. Most companies apply the checklist model to both categories, which under-serves the first one badly.

What changes in the audit trail when AI writes the code

A question that comes up directly once a team starts generating a meaningful share of its code with AI: does the evidence an examiner would look at change, and if so, how.

The obligation itself does not change. The model law does not care who or what wrote the code that enforces a notification deadline, only that the deadline is met. What does change is the shape of the evidence available to show the control existed and operated correctly, and it changes in a direction that is genuinely useful if the team builds for it deliberately.

Generated code, produced from an explicit specification and checked by an independent test suite, leaves a cleaner trail than code written directly by a person against an informal understanding of the requirement. The specification itself becomes an artifact: a written statement of what the notification workflow, or the access control rule, or the reconciliation check is supposed to do, which exists before the code and can be compared against the model law's text directly. Translating NAIC model law into engineering requirements covers building that specification layer. An examiner asking "how do you know this control does what the law requires" can be shown the specification, the generated implementation, and the independent check that verifies the implementation matches the specification, three linked artifacts rather than one person's word that the code is correct.

The part that has to be built in, not assumed, is independence between the code and its verification. Veracode's spring 2026 testing across more than 150 models and 80 coding tasks found that only 55 percent of generations produced secure code, while syntax correctness stayed above 95 percent [2]. A generated notification workflow that runs without error is not evidence it meets a 3-business-day deadline under load, or that it correctly excludes an exempt policyholder category. The check that verifies those things has to be written from the requirement, independently of the model that wrote the workflow, or the audit trail is circular: the same process that might have missed the requirement is also the one certifying that it was met.

Handled this way, AI-generated code does not weaken the evidence available to an examiner. It strengthens it, because the specification-check-implementation chain is more explicit and more testable than the version of the same control built by a person working from memory of a requirement they read once. Handled without that independence, the speed of generation just produces more code that has not actually been verified, faster than a team could produce it by hand, which is the risk this entire hub returns to repeatedly.

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.