Building compliant software in insurance / Start here
Translating NAIC model law into engineering requirements
The NAIC Insurance Data Security Model Law is written in legal language, for legislatures to adopt and lawyers to interpret. Somewhere between that text and a running application, somebody has to convert it into behavior a system can be tested against. This page covers that conversion, using the model law's own sections as the working example.
Key takeaways
- Split the model law's requirements into what a person or process satisfies and what only the running system can satisfy. Only the second set is engineering work.
- Convert each system requirement into an assertion with a subject, an action, and an observable result.
- The model law's risk-assessment requirement is a process obligation with a system consequence: the program has to reflect a current assessment, which the application can check for staleness.
- Trace every check back to the specific section of the model law it satisfies, so a reviewer can audit the mapping instead of trusting it.
The NAIC Insurance Data Security Model Law reads like legislation, because it is legislation, drafted as a template for state legislatures to adopt. Reading it and building against it are two different skills, and the step between them, converting legal language into a specific, testable system behavior, is where most real compliance gaps start.
This page walks that conversion using the model law's own structure.
Step one: split what reaches the code from what does not
The model law covers a mix of process obligations and system obligations, and conflating them is the first mistake. "Designate one or more employees ... responsible for the information security program" [1] is a process obligation. No line of code satisfies it. "Develop, implement, and maintain a comprehensive written information security program based on the licensee's risk assessment" [1] straddles both: the program itself is written by people, but a program that has not been updated to reflect the current system is not really based on an ongoing risk assessment, and that staleness is something software can detect.
Do this split explicitly, in a document, with the model law's section quoted next to each item. It is the highest-value artifact in the exercise, because the check suite you eventually build traces back to it.
Step two: convert each system obligation into an assertion
Take the incident response and notification requirement. Most states that adopted the model law require notifying the commissioner of insurance within a set number of business days of determining a breach occurred, commonly 3 business days in the states that adopted that figure [2], and notifying affected consumers within a state-specific window as well.
Converted into assertions, that single requirement becomes at least three:
A breach determination event exists and is timestamped. Subject: any confirmed unauthorized access event. Action: determination is logged. Observable: a timestamped record exists marking the moment the determination was made, which is the moment the clock the model law describes actually starts.
The commissioner notification fires within the state's window. Subject: the notification workflow. Action: send. Observable: a notification record exists with a send time no later than the determination time plus the state's day count.
Consumer notification fires within the state's window, addressed to the correct policyholders. Subject: the affected policyholder set. Action: notify. Observable: every policyholder whose data was in the affected scope has a notification record, and nobody outside that scope does.
That third assertion is the one most systems fail, not because the notification logic is wrong, but because determining who was actually affected by a given breach depends on data lineage the application usually was not built to answer quickly. Incident response and breach notification in your application covers the mechanics of building that lineage in.
Step three: watch for the words that hide gaps
Two patterns in the model law's language account for most of the gaps we would expect to find.
"Based on." The requirement that the security program be based on the licensee's risk assessment [1] is easy to satisfy on paper with a program document that cites an assessment from three years ago. It is much harder to satisfy in the spirit the model law intends, which is that the program still reflects the risks the current system actually carries. A useful engineering proxy is staleness: if the risk assessment predates the most recent significant architecture change, the "based on" claim is questionable, and that comparison is a check a system can run.
"Appropriate." Several sections require "appropriate" safeguards, oversight, or access controls, without specifying a number. Appropriate is doing real interpretive work in that sentence, and teams tend to read it as whatever they already do. Converting an appropriateness standard into a testable assertion means picking a defensible, documented interpretation, such as least-privilege access scoped to job function, and writing the check against that interpretation rather than against the word itself.
Step four: trace every check to a section
Every check derived from the model law should reference the specific section it exists to satisfy. Not "security check" but the model law's numbered section.
This matters for two reasons. It makes the mapping auditable: a reviewer can put the obligation list beside the check suite and see which obligations have no check attached. And it makes state variation manageable, since when a particular state's adopted version of the model law differs from the template, whoever maintains the configuration can find every check that depends on the relevant section in one search rather than by memory.
Step five: write the check before the implementation
This is the ordering rule from eval-driven development, and it applies here with the same force it applies everywhere else in regulated work.
A check written after the code encodes what the code already does. If an engineer reads the notification service, sees it fires within five days, and writes a test asserting a five-day window, the test will pass regardless of whether five days satisfies the state the policyholder is actually in. Written from the model law's text first, the same check starts from the state's actual required window and fails immediately if the implementation used the wrong number, which is exactly the failure worth catching before an examiner does.
What this produces
At the end of this exercise, you have three things that fit together: a list of model law sections with their text quoted, a set of assertions derived from them, and a check suite where every check names its source section. An obligation with no check attached becomes visible at a glance, which is the actual deliverable. Most insurance software teams cannot currently answer "which of our state notification obligations are enforced by something that runs," and getting to a state where the answer is a list is most of the work described on this page.
The next page in this guide, state-by-state data security requirements for insurance software, covers how to structure that state variation once the assertions exist. Get in touch if you want help building the mapping for your own product.
Best for
- Teams that have a written information security policy but have not checked whether the running system still matches it
- Products expanding into new states, where the translation exercise reveals which state-specific numbers are missing
Avoid if
- Nobody has yet decided which states' adopted versions of the model law apply to the business, since translation depends on that scoping being done first
Verify before you commit
- Ask to see the document splitting process obligations from system obligations, with the model law section quoted next to each
- Ask whether any check was written after the implementation it verifies, rather than before
- Ask which specific model law section each check traces back to
Common questions
How do you decide which parts of the NAIC model law are engineering work?
Split them by what satisfies them. If a person or a documented process satisfies the requirement, it is not engineering work, and no code changes as a result. If only the running system's behavior can satisfy it, such as notifying policyholders within a state's deadline, it is engineering work with a testable outcome.
What makes a model law requirement into a testable assertion?
It needs a subject, an action, and an observable result. The requirement to notify the commissioner within a set number of days becomes an assertion that a notification record exists with a send time no later than the breach determination time plus the state's day count, which a system can check automatically.
Why does the phrase 'based on' matter in the model law's risk assessment requirement?
Because a security program can cite an old risk assessment and technically satisfy the letter of the requirement while no longer reflecting the risks the current system actually carries. A useful engineering check is staleness: comparing the risk assessment's date against the most recent significant architecture change.
How should a team handle the word 'appropriate' in the model law?
By picking a specific, documented interpretation and testing against that interpretation rather than against the word itself. For access controls, a common and defensible interpretation is least-privilege access scoped to job function, which converts an open-ended standard into something a check can verify.
Why should each compliance check reference a specific model law section?
The reference makes the mapping auditable rather than assumed, and it lets a state's differing requirements be handled by search rather than memory. Without that trace, checking coverage means guessing at intent from test names, which does not scale as the company enters more states.
Does it matter if a compliance check is written after the notification logic already exists?
Yes, and it matters more here than in most contexts. A check written afterward can pass while encoding the wrong deadline for a given state, because it copied the implementation's behavior rather than the state's actual requirement. Writing the check from the model law's text first is what catches a wrong number before an examiner does.
How is translating the NAIC model law different from translating a single federal rule?
A single federal rule has one operative text to translate. The NAIC model law is a template that each state adopts with its own numbers, so the translation exercise produces a set of assertions per section plus a configuration layer that holds the state-specific values, rather than one fixed answer.
How long does this translation exercise typically take?
Splitting the model law's sections into process versus system obligations is a bounded exercise, roughly comparable to translating any single regulation, once the right people are in the room. Converting each system obligation into a traced assertion takes longer and scales with how many states' versions the business needs to represent, but the work is mechanical once the split is done.
References
- [1] NAIC, Insurance Data Security Model Law (#668), adopted 2017: requires a designated employee responsible for the information security program and a written program based on the licensee's risk assessment.
- [2] NAIC, Insurance Data Security Model Law (#668): breach notification to the commissioner of insurance within a set number of business days of determination, commonly 3 business days in states that adopted that figure, with a separate window for consumer notification.
Related reading
What a good technical spec looks like when a model writes the code
The old advice was to keep specs short and stop where writing the code is faster. That advice assumed a person was reading it. When a model writes the code, the cost of an unanswered question moves, and so does the right length of a spec.
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.