NAIC Model 668 keeps third-party access inside the insurer’s security program
The NAIC Insurance Data Security Model Law places third-party service providers inside the licensee’s risk assessment, safeguards, due diligence, contract, oversight, incident response, and reporting framework. Outsourcing a core or claims function does not turn the provider’s security program into the insurer’s complete evidence.
Editorial figure by Claims Core Ledger. Source context: NAIC — Insurance Data Security Model Law 668.
The model assigns the program to the licensee
Model 668 describes a written information security program for each licensee within its scope, calibrated to the organization and the information at risk. Third-party service providers are one of the factors that shape that program; they are not a separate universe outside it. The licensee still needs to identify risks, designate responsibility, select safeguards, and maintain evidence appropriate to its own information systems and nonpublic information.
For a core, claims, billing, analytics, or managed-service relationship, the system record should identify the service, connected systems, information categories, access paths, responsible business and security owners, applicable contractual controls, monitoring evidence, exceptions, and change dates. That structure supports review but does not determine whether any safeguard or program satisfies an adopted state requirement.
Due diligence and contractual measures are different controls
The model calls for due diligence when selecting third-party service providers and for providers to implement appropriate measures protecting accessible information and systems. Selection evidence and a contract answer different questions. Due diligence records what was examined and concluded at a point in time; contract terms establish obligations and rights; ongoing evidence shows what happened after access began.
A buyer demonstration should connect the approved provider and service to the signed terms, systems and data in scope, access changes, assurance evidence, findings, remediation, exceptions, and renewal decision. A certification or questionnaire can contribute evidence, but the model does not make a badge a substitute for the licensee’s risk assessment, oversight, incident response, or accountable approval.
Material change should reopen the security record
Model 668 calls for adjustment of the information security program when technology, threats, business arrangements, outsourcing, and related circumstances change. Core modernization routinely changes interfaces, hosted environments, support access, subcontractors, data movement, and operational dependencies. A provider approved for the original design may need a new review when those facts move.
Insurance systems should preserve a dated relationship graph rather than one current vendor profile. When a service, data flow, hosting arrangement, or downstream provider changes, the record should identify affected controls, evidence requested, interim treatment, approver, and completion state. That does not mean every change has the same risk; it means the basis for not reopening a decision remains inspectable.
Adoption and event duties remain jurisdiction-specific
Model 668 is an NAIC model law, not a single self-executing national rule. State adoption, amendments, definitions, exemptions, regulator guidance, effective dates, and the facts of an event determine actual obligations. The model’s treatment of cybersecurity events involving third-party systems shows why incident records need the provider, affected licensee systems or information, notice timing, investigation facts, and jurisdictional analysis kept separate.
Claims Core Ledger will continue to distinguish the model text from each jurisdiction’s enacted record. This article does not establish that an insurer, licensee, provider, event, or system is in scope. It also does not decide whether a safeguard is appropriate, an incident is reportable, or a governing body has received sufficient information.
Enterprise buyer test
Translate this change into the exact population, record type, workflow stage, decision owner, effective date, and evidence that could be affected. Ask current or prospective providers to demonstrate the named workflow with representative data and an exception—not a polished feature tour. Record what official documentation establishes, what a provider states, what the team observes, and what remains unresolved.
A defensible review also identifies the dependency outside the product. Authority interpretation, policy configuration, data quality, integrations, human judgment, approval rights, release governance, training, and retained evidence may remain customer or service responsibilities. The evaluation should preserve those boundaries instead of treating a technology claim as the complete operating model.
What we will watch next
Claims Core Ledger will watch the named source and affected market records for later evidence that changes status, scope, availability, implementation timing, workflow consequence, or the limits of the initial report. A later announcement does not silently overwrite this dated account; the change ledger preserves the sequence.