If your product touches an insurance carrier's policyholder data, NAIC model law software vendor compliance is no longer a hypothetical you can defer to legal. Since South Carolina became the first state to adopt the NAIC Insurance Data Security Model Law in 2018, more than 20 states have followed with their own versions of the same framework, and every one of them makes insurers responsible for vetting the security of the vendors who process, store, or transmit "nonpublic information" on their behalf. That responsibility flows downhill fast: carriers are now sending detailed security questionnaires, contract riders, and audit requests to policy administration platforms, claims software, telematics providers, and every SaaS tool that touches an insurance workflow. Vendors who can't answer those questions with evidence, not promises, are losing deals or getting dropped mid-renewal. This post breaks down what the model law actually requires, why it reaches your company even though you're not an insurer, and how to get ahead of it.
What Is the NAIC Insurance Data Security Model Law?
The NAIC Insurance Data Security Model Law (designated MDL-668) is a template statute the National Association of Insurance Commissioners adopted in October 2017 to give state insurance regulators a consistent cybersecurity framework, and it requires licensed insurers, agents, and reinsurers to build, document, and maintain a written information security program. The model law was drafted in the wake of large-scale breaches at companies like Anthem and Equifax, and it borrows heavily from the New York Department of Financial Services' 23 NYCRR 500 regulation, which predates it by about a year. Unlike NYCRR 500, though, MDL-668 isn't a single state's rule — it's a template that each state legislature adopts, sometimes with tweaks, which is why compliance obligations differ slightly depending on where a carrier is domiciled and licensed. At its core, the law requires a risk-based information security program, a designated individual accountable for that program, a formal incident response plan, and — critically for software vendors — documented oversight of third-party service providers.
Which States Have Adopted the Model Law, and Does It Matter Where You Sell?
Yes, it matters, because adoption is state-by-state and each state's insurance commissioner enforces its own version. South Carolina was first in 2018, followed quickly by Ohio, Michigan, Mississippi, and Alabama in 2018–2019, then Delaware, New Hampshire, Connecticut, Louisiana, Indiana, Iowa, Virginia, North Dakota, Hawaii, Maine, Kentucky, Minnesota, Illinois, Wisconsin, Rhode Island, Vermont, Tennessee, Pennsylvania, and Alaska in the years since. As of 2026, more than 20 states representing a majority of U.S. premium volume have enacted some form of the model law, and NAIC continues to push for adoption in the remaining states, including large markets like California, Texas, Florida, and New York that either have their own comparable statutes or are actively considering the model law. If your customers include insurers licensed in any of these states — which, for most B2B insurtech and claims-software vendors, is functionally all of them — you are already inside the compliance perimeter, whether or not your own company is domiciled there.
How Does the Model Law Apply to Software Vendors Who Aren't Insurers?
It applies indirectly but forcefully, through the model law's third-party service provider provisions, which require licensed insurers to exercise "due diligence" in selecting any vendor with access to nonpublic information and to require those vendors to implement appropriate administrative, technical, and physical safeguards. In practice, this means an insurer cannot simply sign a contract with a software vendor and move on — the licensee must document its evaluation of the vendor's security posture before onboarding, and many states' versions of the law require ongoing monitoring for the life of the relationship. Nonpublic information under the model law is defined broadly to include not just policyholder Social Security numbers and financial account numbers, but also health information and any information that could be used to commit identity theft. A claims-processing platform, a policy administration system, an underwriting API, or even an analytics vendor that ingests loss-run data all fall inside this definition, which is why insurers are pushing security questionnaires down to vendors that never considered themselves part of the insurance industry's regulatory perimeter.
What Does NAIC Model Law Software Vendor Compliance Actually Require?
In practice, it requires vendors to produce the same categories of evidence an insurer's own examiner would expect internally: a documented risk assessment, a written information security program covering access controls, encryption of nonpublic information at rest and in transit, multi-factor authentication, and a tested incident response plan. Most state versions of the law also require notification to the insurance commissioner within 72 hours of determining that a cybersecurity event has occurred and has a reasonable likelihood of materially harming a consumer — a timeline vendors need to be contractually prepared to support, since insurers will push equivalent or tighter notification windows into vendor agreements (24 to 48 hours is now common). Vendors are also increasingly asked to certify annually that they maintain these controls, to provide SOC 2 Type II reports or equivalent independent attestations, and to disclose their software supply chain — including open-source dependencies, subprocessors, and any fourth-party vendors who touch the same data. This last requirement is where many vendors get caught flat-footed: they can describe their own controls but can't produce an accurate, current inventory of the components and dependencies running in their product.
How Are Insurers Building TPRM Programs Around the Model Law?
Insurers are formalizing insurer TPRM (third-party risk management) programs specifically to satisfy their model law due-diligence obligations, and that means every vendor relationship now runs through a structured intake, assessment, and ongoing-monitoring workflow instead of a one-time procurement checklist. A typical program tiers vendors by data sensitivity and access level, requires higher-risk vendors (anyone touching claims, underwriting, or PII at scale) to complete detailed security assessments before signing, and schedules reassessment annually or upon contract renewal. Because state insurance cybersecurity regulation holds the licensee — not the vendor — accountable to the commissioner, insurers have strong incentive to over-collect evidence rather than under-collect it, and vendor security teams are seeing the volume and depth of these questionnaires increase year over year. Some carriers now require real-time or continuous visibility into a vendor's security posture rather than point-in-time attestations, mirroring the shift already underway in other regulated industries toward continuous compliance monitoring.
What Happens If a Vendor Falls Short — Who's Actually at Risk?
The direct regulatory penalty falls on the insurer, but the commercial risk falls squarely on the vendor: state insurance commissioners can fine and sanction the licensee, not the software company, yet insurers are responding by writing indemnification clauses, security SLAs, and termination-for-cause provisions into vendor contracts that shift real financial exposure onto vendors who can't demonstrate compliance. In several states, penalties for licensees can reach tens of thousands of dollars per violation, plus mandated remediation and increased examination scrutiny — costs insurers pass through contractually or simply avoid by choosing a better-prepared competitor. The more common outcome isn't a fine at all; it's a stalled or lost deal, a failed renewal, or a vendor security review that drags a six-figure contract into a multi-month standoff because the vendor can't quickly produce an SBOM, a current vulnerability disclosure, or evidence of dependency monitoring. In a market where insurers are comparing multiple vendors for the same capability, the one with clean, current, exportable security evidence wins the deal.
How Safeguard Helps
Safeguard was built for exactly this moment: software vendors who need to prove supply chain and application security posture to regulated customers, fast, and keep proving it without reinventing the process for every insurer's questionnaire. We help vendors pursuing NAIC model law software vendor compliance generate and maintain accurate SBOMs across every build, continuously scan dependencies for known vulnerabilities and license risk, and produce provenance and attestation evidence that maps directly to the due-diligence documentation insurer TPRM teams are now requesting as standard practice. Instead of scrambling to answer a security questionnaire from scratch every time a carrier's procurement team asks, Safeguard customers maintain a living, exportable record of their security controls, dependency inventory, and remediation history that satisfies both the letter of state insurance cybersecurity regulation and the practical, ongoing-monitoring expectations insurers are building into their vendor programs. That means fewer stalled renewals, faster security reviews, and a defensible answer the moment an insurer asks how you protect the nonpublic information running through your platform. If your roadmap includes insurance customers in any of the states that have adopted the NAIC Insurance Data Security Model Law — and at this point, that's most of the country — getting your supply chain evidence in order now is cheaper than doing it under deadline during a renewal cycle.