State-by-state data security requirements for insurance software

A team that reads the NAIC Insurance Data Security Model Law once and implements "the" notification rule has usually implemented one state's version of it, whichever state they happened to be looking at. That is a reasonable mistake to make once. It becomes a real liability the moment the company is licensed in a second state whose adopted version differs.

Why the variation exists

The NAIC drafts model laws as templates for state legislatures. A state legislature can adopt a model law as written, adopt it with amendments, or decline to adopt it at all. The Insurance Data Security Model Law has been adopted by more than 25 states as of early 2026 [1], and the versions differ in specifics: how many business days a licensee has to notify the commissioner after determining a breach occurred, the number of affected consumers that triggers a notification requirement, and which categories of licensee, such as smaller agencies below a certain size, are exempt from parts of the law.

This is not a minor detail to smooth over. A notification sent on the deadline for one state, applied to a policyholder in a state with a shorter window, is a missed deadline, and a missed deadline is exactly the kind of finding an examination exists to surface.

What a configuration-first design looks like

The practical fix is to treat the state-specific numbers as data, not as logic. A table, keyed by state, holding at minimum: the number of days to notify the commissioner, the number of days to notify affected consumers, the size threshold that triggers a notification obligation if the state has one, and any exemption that applies to the licensee's category of business in that state.

The application's notification workflow then looks up the relevant row based on the policyholder's state, rather than embedding a specific day count in the workflow's code. Adding a new state, once the company gets licensed there, becomes an entry in that table, reviewed by whoever is responsible for tracking the state's actual adopted requirements, rather than a change to application logic reviewed by an engineer who is not positioned to know whether the new state's deadline is 3 business days or 5 calendar days or something else entirely.

The check that actually matters here

Configuration alone is not the safeguard. The safeguard is a check that compares the configuration table against the list of states the company is actually licensed in, and fails when the two do not match.

This catches the single most common failure mode we would expect to find in a growing insurance company's software: a state gets added to the list of active licenses, sales and underwriting start writing policies there, and nobody tells the engineering team, because from their perspective the application already works everywhere. Six months later a claim in that state triggers an incident, and the notification workflow either uses a default that may not match the state's actual requirement or fails outright because no row exists.

The check itself is simple to state and worth writing before the configuration table is even fully populated: for every state where the company holds an active license, assert that a configuration row exists, and assert that the row's values were reviewed within some defined period rather than inherited unchanged from when the state was first added. That second half matters because states amend their own adopted versions over time, and a row that was correct in 2022 is not guaranteed to still be correct.

Multi-state policyholders and the harder edge case

A subtler case worth naming: a policyholder can move states after a policy is written, or a business policyholder can have operations spanning several states. Which state's rule applies to a breach affecting that policyholder is a legal question, not a technical one, but the application has to be able to represent the answer once counsel has one. That means the data model needs to track the state relevant to notification, which is not automatically the same as the mailing address on file, and the notification workflow needs to be able to apply more than one state's rule to a single incident when the affected population spans states, which is the normal case for any insurer operating regionally.

Exemptions are part of the same table

States that adopted the model law frequently carved out exemptions, commonly for licensees below a certain size or for those already subject to an equivalent federal standard. An exemption is not a reason to skip building the configuration entry for that state. It is a value in the same table: whether the exemption applies to this specific business, in this specific state, verified by counsel, represented as data so a change in the business's size or structure can be checked against it rather than assumed to still hold.

Building this alongside the notification workflow itself

State-by-state configuration is the input side of the requirement. What the application does once a breach is determined, how quickly it identifies affected policyholders and fires the correct notifications, is covered on incident response and breach notification in your application, which picks up directly from the configuration structure described here.

Building the configuration mechanism correctly the first time, even while the company only holds a handful of licenses, is cheaper than discovering the gap after the fifteenth state is added under sales pressure and nobody remembered to revisit the notification logic. If your application currently has a single hardcoded notification rule and you are licensed in more than one state, that is the first thing worth checking. Get in touch if you want a second opinion on what your current configuration actually covers.