The NAIC Data Security Law: What It Requires in 2026

The NAIC Insurance Data Security Model Law (#668) requires insurers, insurance agents, and other state-licensed entities to build a written information security program, investigate breaches, and notify their state insurance commissioner within 72 hours of one — and as of the NAIC’s own August 2025 count, 27 states plus Puerto Rico have already written it into law. Most independent agents have never heard of it, because it doesn’t market itself the way a CMS marketing rule does. There’s no AEP deadline attached to it, no certification exam, nothing that shows up on a carrier’s annual checklist. It just sits in your state’s insurance code, applying to you whether you’ve read it or not.

The pain: a law you’re already subject to and have never read

Here’s how this usually surfaces. An agent renews their E&O, reads the exclusions carefully after last year’s scare about AI-related gaps, feels good about it, and moves on. Nobody mentions that the state they’re licensed in passed its own version of the NAIC Insurance Data Security Model Law two or three years ago, that it explicitly names “insurance agents” as covered parties, and that it comes with its own commissioner-notification clock that runs independently of anything CMS, HIPAA, or an E&O carrier requires.

This isn’t a hypothetical gap. The model law was written specifically because state insurance regulators watched several major insurer data breaches happen with no uniform data-security floor underneath the industry, and it names individual agents as covered parties in its very first substantive sentence, not as an afterthought (NAIC, Model Law MO-668, Section 2). If your state adopted it, you’re covered by it right now, whether or not anyone at your FMO, your carrier, or your last CE course ever mentioned it.

What the model law actually says

The NAIC adopted the Insurance Data Security Model Law in October 2017, following roughly two years of drafting after a wave of large insurer data breaches pushed state regulators to build a common security floor (NAIC, Government Affairs Brief, August 2025). The model’s own definitions section is unambiguous about who it reaches: “Licensee” means “any Person licensed, authorized to operate, or registered, or required to be licensed, authorized, or registered pursuant to the insurance laws of this State” (NAIC, Model Law MO-668, Section 3). A licensed individual producer is a Person licensed under a state’s insurance laws. That’s you, not just the carrier whose products you sell.

Once a state enacts its own version of the model — and the specific text can vary state to state, since a model law is a template legislatures adapt, not a self-executing federal statute — three obligations follow for a covered Licensee:

1. Section 4 requires developing, implementing, and maintaining “a comprehensive written Information Security Program based on the Licensee’s Risk Assessment,” sized to the Licensee’s own size, complexity, and the sensitivity of the Nonpublic Information it holds (NAIC, Model Law MO-668, Section 4(A)).
2. Section 5 requires investigating a Cybersecurity Event when one is discovered.
3. Section 6 requires notifying the state insurance commissioner of a Cybersecurity Event that meets specific triggers, within 72 hours of determining it occurred.

The model doesn’t create a private right of action — a client can’t sue you directly under this specific law for a violation of it — and it doesn’t limit whatever private right of action already exists under other law (NAIC, Model Law MO-668, Section 2(B)). What it does give your state’s insurance commissioner is real teeth: the power to examine and investigate a Licensee’s compliance and the authority to order remediation of anything deficient found during that examination (NAIC, Government Affairs Brief, August 2025).

Are you actually exempt? Read Section 9 before you assume

This is the section most agents get wrong in both directions — some assume they’re covered by a carrier’s program when they’re not, and some assume they need their own written program when a real exemption already covers them. The model law’s Section 9 lists three specific exceptions, and only the first two get discussed much online.

Three things about this table matter more than the exemptions themselves. First, all three exemptions apply to Section 4 only — the written-program requirement. None of them touch Section 5 (investigate a Cybersecurity Event) or Section 6 (notify the commissioner within 72 hours). A two-person agency exempt from ever writing a formal Information Security Program still has to investigate a breach and still has the same 72-hour clock as a national carrier.

Second, the third exemption is conditional on actual coverage, not on titles. “Agent of a Licensee” doesn’t mean “anyone who holds an insurance license and works with a bigger company.” It means your work is genuinely covered by that other Licensee’s own written Information Security Program — their CRM, their vendor contracts, their risk assessment. The moment you run your own separate CRM, your own separate lead vendor relationships, and your own separate AI tools that the carrier’s program was never written to cover, you’re very likely back to being the responsible Licensee for whatever isn’t covered.

Third, if an agency stops qualifying for any exemption — it hires its tenth employee, say — Section 9(B) gives it 180 days to come into compliance, not zero (NAIC, Model Law MO-668, Section 9(B)). That’s a real grace period, and it’s worth knowing the number instead of guessing at it.

If Section 4 applies to you, here’s what it actually asks for

For a Licensee that isn’t exempt — a multi-person independent agency running its own systems is the clearest case — Section 4 doesn’t ask for a specific vendor, a specific software purchase, or a specific certification. It asks for a written program built around a real risk assessment, with four objectives named directly in the text: protect the confidentiality and security of Nonpublic Information and the Information System that holds it; protect against threats and hazards to that information; protect against unauthorized access and minimize harm to any consumer; and define, and periodically reevaluate, a retention and destruction schedule for that information (NAIC, Model Law MO-668, Section 4(B)).

The risk assessment itself has specific, checkable components under Section 4(C):

None of this requires a specific product. A one-page document naming who’s responsible, what threats you considered, what you already have in place, and when you’ll review it again is a real Information Security Program in the sense the statute means, provided it’s actually written down and actually reflects what you do.

The 72-hour clock, and what has to be in the notice

Section 6 is the part with the least room for interpretation, because it’s built around a specific number: notify the commissioner “as promptly as possible but in no event later than 72 hours from a determination that a Cybersecurity Event has occurred” (NAIC, Model Law MO-668, Section 6(A)). That clock only starts once you’ve made a determination — not the instant something suspicious happens — but once you’ve made it, the countdown is real and doesn’t extend for a weekend or a slow IT vendor.

The obligation is triggered when either of two conditions is met:

Once notified, the reporting duty doesn’t end with one email. Section 6(B) requires as much of a growing list of details as possible, in electronic form as the commissioner directs, with “a continuing obligation to update and supplement” the notice as more is learned: the date of the event, how the information was exposed or stolen, how it was discovered, whether it’s been recovered, the identity of the source if known, whether law enforcement has been notified, the specific types of information taken, how long the system was compromised, and a running best estimate of the total number of state residents affected (NAIC, Model Law MO-668, Section 6(B)).

Which states have adopted it

A model law only has legal force once a state legislature actually enacts it — the NAIC drafts the template, but each state writes and passes its own version, sometimes with local variations. As of the NAIC’s own Government Affairs Brief dated August 2025, 28 jurisdictions had implemented Model Act #668.

If your state shows “No” here, that’s not necessarily the end of the story — the NAIC’s April 2026 tracker map shows continued movement, and several “No” states have introduced versions of the model that haven’t passed yet. It’s also not a reason to skip the rest of this article: general cybersecurity practice, HIPAA obligations, and your own carrier contracts likely require most of the same things regardless of whether your specific state has enacted this exact model.

What it costs when a real regulator finds a real gap

New York never adopted the NAIC model law — it has run its own, earlier cybersecurity regulation for financial services and insurers, 23 NYCRR Part 500, since 2017. The two frameworks aren’t the same law, but they’re built around the identical core idea: a written cybersecurity program, and real penalties when a regulator finds one that exists on paper but not in practice. On October 14, 2025, New York’s Department of Financial Services announced it had secured more than $19 million in combined penalties from eight auto insurance companies over a set of 2021 data breaches that exposed driver’s license numbers and dates of birth (New York DFS, press release, Oct. 14, 2025).

DFS’s own account of what went wrong is the part worth reading closely, because none of it describes some exotic hacking operation. The companies “did not comply with DFS’s cybersecurity regulation, which requires them to implement policies, procedures, and controls designed to protect consumer data” — specifically, inadequate controls on “public-facing web applications and agent portals” let unauthorized parties reach consumer data, and two of the eight companies were separately cited for failing to report the events to DFS on time (New York DFS, press release, Oct. 14, 2025). “Agent portals” is the detail worth sitting with. The gap wasn’t in some back-office mainframe nobody touches — it was in the exact kind of consumer-facing, agent-facing web tooling an independent agency runs every day. A written program with an actual review cadence is what’s supposed to catch a gap like that before a regulator does.

The manual fix: build a real Information Security Program this week

None of the following requires software, a vendor, or a membership. It requires an afternoon and a willingness to write down what you already do — and what you don’t.

That’s the whole program at a starting level: a named responsible person, a system inventory, a threat list, a safeguards list, and a review date, all in one written document. It won’t be a polished consultant-built policy on day one, and it doesn’t need to be — it needs to exist, be accurate, and get revisited.

Where AI adds a new version of this exact problem

Section 4’s third-party service provider language was written years before generative AI tools were something a solo agent used daily, but it reaches them cleanly: any vendor that touches your Nonpublic Information, including an AI tool, falls inside the risk assessment and oversight the model asks for. A consumer AI chatbot with no Business Associate Agreement and no enterprise data controls is exactly the kind of third-party exposure Section 4(C)(2) has in mind when it names threats “accessible to, or held by, Third-Party Service Providers.”

We’ve written the general version of this risk in detail in What Not to Paste Into ChatGPT. The specific overlap with this law is worth naming directly: a written Information Security Program that never mentions AI tools at all isn’t a complete risk assessment anymore, and an agency’s GoHighLevel setup deserves the same scrutiny — see our breakdown of what your AI can and can’t see inside a HIPAA-enabled GoHighLevel sub-account for a concrete example of a vendor boundary most agents assume is airtight and haven’t actually checked.

Where Ambrose’s architecture closes a real technical gap, and where it doesn’t

Nothing in what follows makes an agency compliant with Section 4. That has to be said plainly, because the temptation to imply otherwise is exactly the kind of overclaim that makes a compliance article useless. Section 4 asks for a written, agency-specific document with a named responsible person and an annual review — a governance exercise, not a technology purchase.

What a platform’s architecture can do is remove some of the technical gaps a written program is supposed to catch in the first place — the same kind of gap DFS found in those “agent portals.” Per Ambrose’s own documentation, fetched this session: Ambrose OS is built as an agentic AI operating system for insurance agencies, where “your book of business lives in an encrypted vault scoped to your agency,” with “every read and write” carrying the agency’s own id, “enforced in the application and in the database” (Ambrose docs, What is Ambrose). Protected health information “only runs against model providers covered by a signed Business Associate Agreement” — Claude, through Amazon Bedrock, in U.S. regions (Ambrose docs, What is Ambrose). Every action an agent takes is logged, and anything that writes to a connected CRM “waits for your approval with Allow, Deny, or Always Allow” before it happens (Ambrose docs, What is Ambrose).

Two specific spokes matter for this exact law. The agent-vault spoke is documented as the “agency’s private book of business,” with a HIPAA posture marked “safe” — data stays local to the tenant and PHI is permitted inside it (Ambrose docs, Spokes). The phi-gateway spoke is documented as a “PHI scrubber + re-hydrator,” also marked “safe” (Ambrose docs, Spokes), and Ambrose’s architecture page names it more specifically as a “pseudonymization proxy” that “scrubs the 18 HIPAA identifiers” before “re-hydrat[ing] on response” (Ambrose docs, Architecture) — meaning identifying details are stripped out before data reaches a destination and restored only for an authorized response, rather than sitting exposed in a request to a third party by default.

Everything in the manual section above works whether you ever look at Ambrose or not — write the program, name the responsible person, list your systems, put the review date on the calendar. Ambrose’s seat is worth mentioning here specifically because the technical gaps it closes — an AI tool with no BAA sitting in your stack, client data with no agency-level isolation, no log of who touched what — are exactly the kind of “we didn’t think to write that down” gaps a commissioner’s examination exists to find.

This is the kind of thing we walk through on a Tuesday call with Ambrose open on the screen — building the actual system inventory, checking which tools in it have a BAA and which don’t, and watching the phi-gateway spoke alias a real client record before it ever reaches a model. $97 a month, cancel anytime, and nobody’s going to pitch you a downline while you’re doing it.

What you get by joining

One Ambrose seat, including the agency-scoped vault, the audit trail and approval gate, and the phi-gateway spoke referenced above, comes included with a Tech Savvy Insurance membership: $97 a month, billed monthly, cancel anytime, with the founding rate locked in while the membership stays active. Ambrose usage runs through its own credit ledger, so cost stays visible instead of becoming a surprise later. Alongside the seat: weekly Zoom calls with open Q&A and build-with-you sessions, more than 30 hours of recorded training, Meta Ads and marketing training built for health and life agents specifically, pre-built AI templates and bot deployments, and a free annual in-person member workshop. It’s also an explicit no-recruiting zone — you can ask a real question about a state cybersecurity rule without getting DM’d about a downline an hour later, which isn’t true of most agent Facebook groups.

Related reading: our full guide on what not to paste into ChatGPT for the AI side of this same risk assessment, what your AI can and can’t see inside a HIPAA-enabled GoHighLevel sub-account for one specific vendor boundary worth checking, and our broader NAIC, CMS, and state AI compliance landscape if the AI Model Bulletin side of NAIC’s work is new to you too.

The close

This law didn’t get written to catch agents doing something wrong. It got written because state regulators watched large insurers lose consumer data with no consistent floor underneath the industry, and it named individual agents as covered parties from the first sentence. Whether your state has enacted it yet or not, the underlying exercise — know your exemption status, name a responsible person, list your systems, write down your gaps, put a review date on the calendar — is worth an afternoon regardless. Do it before an examination or a breach makes you do it under pressure, not after.