Building compliant software in insurance / Start here
Why insurance software needs a compliance-first build
Most insurance software gets built first and made compliant second, usually right before a launch date or a renewal audit forces the question. That order costs more than it saves, because the requirements that matter most, the ones tied to state law, are easiest to satisfy when they shape the data model from the start rather than get bolted onto one that was not built with them in mind.
Key takeaways
- Retrofitting state-specific notification logic onto an application not built for it usually means finding out how many places a policyholder's state is assumed rather than looked up.
- A compliance-first build treats the NAIC model law's requirements as specifications from the first data model decision, not as a checklist run before launch.
- The state variation in insurance law rewards building one configurable mechanism early rather than patching in exceptions later.
- This only works if the checks derived from those specifications are independent of the code that implements them.
Insurance software teams tend to treat compliance as the last mile: build the product, get it working, then run it past the state requirements before launch. For most kinds of software that order is fine, because most requirements are cosmetic enough to retrofit. Insurance data security requirements resist that retrofit for a specific reason: they are keyed to a piece of data, the policyholder's state, that either lives in your data model as a first-class fact from day one or gets reconstructed later at real cost.
What retrofitting actually costs
Picture an application built without state-specific logic in mind, because at launch the company was licensed in three states and a single notification rule felt sufficient. Two years and twelve state licenses later, someone asks: if a breach happened today, could this system tell us which policyholders need to be notified within three business days and which within a different window their state requires?
Answering that honestly usually means an audit of every place the code assumes a single jurisdiction. The breach notification service. The consent language shown at signup. The data retention job that ages out records after a fixed period regardless of what a given state requires. Each of these was written once, correctly, for the three states that existed at the time, and none of them was revisited when the ninth state was added, because adding a state felt like a legal event, not an engineering one.
Why "compliance-first" means something concrete here
Being compliance-first is not a mindset. It means specific decisions, made early, that are cheap at the start of a build and expensive to retrofit later.
Store the policyholder's state as a first-class, queryable field, not inferred from a mailing address parsed at render time. Every downstream rule that varies by state depends on this being reliable.
Build the notification timeline as a lookup, not a constant. A configuration table keyed by state, holding the number of days, the size threshold, and any exemption, so that adding a fourteenth state is a data change reviewed by whoever tracks the legal requirement, not a code change reviewed by an engineer guessing at the number.
Log access to policyholder data from the first version, even the internal version nobody outside the company sees yet. Adding logging to an existing system means finding every path that touches the data and instrumenting it after the fact, which is exactly the kind of exhaustive, unglamorous work this hub's pillar page argues is now affordable to do properly rather than skip.
The state adoption problem specifically
The reason insurance is a harder version of this problem than most regulated industries is that the underlying law is a template each state legislature adopts on its own schedule, and the version a state adopts can differ in the notification deadline, who is exempt, and what counts as a reportable event. Our page on state-by-state data security requirements for insurance software covers the specific mechanics of building for that variation.
Building for one state and generalizing later means the generalization happens under time pressure, usually right after the company gets licensed somewhere new and discovers the application cannot represent the difference. Building the mechanism once, even while only three states are active, means the fourteenth state is a data entry, not a sprint.
Where AI-native development changes the calculation
The reason to do this early rather than "when we have time" is the same reason this whole hub exists: the cost of doing it thoroughly changed. Writing a state-configuration table with the correct notification window, threshold, and exemption for twenty-five adopting states, plus a check that fails if a licensed state has no configuration entry, used to be a specification exercise nobody funded before it was urgent. It is now an afternoon of research plus a run that repeats on every change.
The condition that makes this actually safe, rather than just fast, is the same one we state plainly across this whole guide: generated code is not secure by default, so the checks that verify the state configuration table has an entry for every licensed state have to be written from the requirement, before the table exists, and graded by something other than the model that wrote the table. Our eval-driven development guide covers that method in general, and it applies here directly.
What a compliance-first build looks like in practice
It does not mean building every state's exact rule before the company is licensed anywhere. It means the mechanism, the place where state-specific values live and the check that verifies coverage, exists from the beginning, even when it only holds two or three states' worth of data.
That small amount of early structure is what turns "we just got licensed in a new state" from an engineering scramble into a configuration update reviewed against the rules that reach your code on the next page in this guide, and it is the difference between a compliance program that keeps pace with the business and one that is always catching up to the last state the company entered.
Best for
- New insurance products, or a rebuild, where the data model can be shaped around state-specific rules from the start
- Companies actively expanding into new states, where a hardcoded single-state rule will fail on the next license
- Teams that want the notification and retention logic to be a data change rather than a code change
Avoid if
- The company operates in a single state with no plans to expand, in which case a simpler fixed rule may be proportionate, though it should still be a named, tested rule rather than an assumption
- Nobody has scoped which states' versions of the model law apply, since a configuration table cannot be correct without that legal input first
Verify before you commit
- Ask whether the policyholder's state is a stored, queryable field or something inferred from an address at render time
- Ask whether the notification deadline and threshold live in configuration or in application code
- Ask what happens when the company gets licensed in a new state: a data entry, or an engineering ticket
Common questions
What does it mean to build insurance software compliance-first?
It means treating state data security requirements as specifications that shape the data model from the beginning, rather than a checklist run before launch. In practice that means storing the policyholder's state as a first-class field, building notification deadlines as configuration rather than a constant, and logging access to policyholder data from the first version of the system.
Why is retrofitting compliance harder in insurance software than in most industries?
Because insurance data security law is a template each state adopts on its own schedule with its own numbers, so a system built for the three states a company started in has to be audited path by path when it expands, to find every place a single jurisdiction was assumed rather than looked up.
What is the specific engineering risk of hardcoding one state's notification rule?
The risk is that the rule is applied to policyholders in a different state where the deadline, threshold, or exemption is different, which can mean missing a shorter notification window entirely. The fix is a configuration table keyed by state rather than a constant written into the application code.
Does a compliance-first build mean implementing every state's rule before launch?
No. It means the mechanism, a place where state-specific values live and a check confirming every licensed state has an entry, exists from the beginning, even if only two or three states are populated at first. Adding a new state later is then a data entry rather than an engineering project.
Is AI-generated code appropriate for this kind of compliance logic?
Only with independent verification, since generated code is not secure by default. Veracode's spring 2026 testing found just 55 percent of model generations produced secure code, so the checks confirming state configuration coverage need to be written from the requirement before the configuration table exists and graded separately from the model that wrote it.
What happens if a company gets licensed in a new state and the application was not built for this?
The team typically discovers the gap under time pressure, often when someone asks whether the system can correctly notify policyholders in the new state and the answer requires tracing through code that assumed a fixed set of jurisdictions. Building the state-configuration mechanism early avoids this scramble entirely.
How does storing a policyholder's state as a first-class field help with compliance?
Nearly every downstream rule that varies by state, including notification timelines and retention periods, depends on reliably knowing which state a given policyholder is in. If that value is inferred from a mailing address at render time rather than stored and validated, every rule built on top of it inherits that unreliability.
Who should be involved in deciding which states' rules apply to an insurance application?
Counsel, not engineering. Scoping which states' adopted versions of the model law apply to a given business is a legal question. Engineering's role starts once that scoping exists, converting the legal requirements into a configuration structure and a check suite that enforces it on every change.
Related reading
Adding eval tests was the best decision we made
We generate every line of code we ship. The single change that made that safe was writing the check before the code, and it turned out to change how we review, how we spec, and how fast we can move.
How many tests does AI-generated code need?
The honest answer is not a number, and coverage percentages are the wrong unit. Here is the unit we use instead, and why a suite of fifteen checks can be worth more than two thousand.