If your insurer operates outside New York, the regulation shaping your security testing is probably the NAIC Insurance Data Security Model Law. It reads a lot like the NYDFS rule, with one difference that changes how you plan a pentest.
Most of the model's requirements run in the background of a mature security program. This article covers the testing question directly, whether Model 668 requires a penetration test, what its risk-based language actually asks for, and how it lines up against the NYDFS regulation you may also answer to.
What CodeAnt AI solves here: CodeAnt AI is a defensive and offensive security platform that runs continuous, code-aware testing across an insurer's applications, APIs, and cloud, producing the testing evidence a risk-based program under Model 668 is built to document.
What the NAIC Insurance Data Security Model Law requires
The model, formally Model 668, was adopted by the NAIC in October 2017 in response to a run of large insurer breaches. Its core demand is structural.
Licensees develop, implement, and maintain an information security program built on their own risk assessment, with a designated employee accountable for it. That program identifies risks, puts controls in place to manage them, oversees third-party providers, and handles investigation and notification of cybersecurity events.
The design philosophy is risk-first. Rather than hand every insurer an identical checklist, the model has licensees choose their security measures through ongoing assessment of internal and external threats.
Does The NAIC Model Law Require Penetration Testing?
Here is the honest answer. Model 668 does not use the words "penetration testing" or set an annual cadence the way NYDFS does.
What it requires instead is that a licensee, based on its risk assessment, regularly test and monitor systems to detect actual and attempted attacks.
For any insurer holding policyholder PII, health data, or payment records, that risk assessment points in one direction. A penetration test is how you demonstrate you have tested for real, exploitable attacks rather than assumed your controls hold.
The model reinforces this on the application side. Licensees adopt secure development practices for in-house applications, and establish procedures to evaluate, assess, or test the security of externally developed ones, which is a direct call for application-level testing.
Which States Have Adopted NAIC Model 668?
Adoption has spread steadily since 2017. The model grew out of high-profile insurer breaches, and the US Treasury pushed states to adopt it within five years or face federal preemption.
As of 2025, more than 20 states have enacted the model or a close variant, including Alabama, Connecticut, Delaware, Indiana, Iowa, Louisiana, Maine, Michigan, Mississippi, Ohio, South Carolina, Tennessee, and Virginia. The list keeps growing, so the practical planning assumption is that if you write business in multiple states, at least one of them holds you to Model 668.
New York is a special case. Because the model was built to align with the NYDFS regulation, an insurer already compliant with 23 NYCRR 500 is generally treated as meeting the model's requirements.
NAIC Model 668 Vs NYDFS 23 NYCRR 500 Penetration Testing Requirements
The two are close relatives, which is by design. The model was written to follow the risk-assessment approach of the New York DFS Cybersecurity Regulation, so the differences come down to prescriptiveness.
Attribute | NAIC Model 668 | NYDFS 23 NYCRR 500 |
|---|---|---|
Basis | Risk assessment | Risk assessment |
Penetration testing | Implied through risk-based testing | Named, at least annually (500.5) |
Scanning cadence | Set by risk assessment | Risk-based, plus after material change |
Scope | Adopting states' licensees | NY-licensed entities |
Cross-recognition | NYDFS compliance generally satisfies it | Its own standalone requirement |
The takeaway for a multi-state insurer is to build to the stricter of the two. A program that satisfies the explicit NYDFS annual test also satisfies the model's risk-based testing, so meeting NYDFS penetration testing requirements covers both.
How NAIC Risk Assessments Should Drive Penetration Testing Scope
Under a risk-based model, the risk assessment is what scopes your test. Done well, it names the systems that hold the most nonpublic information and ranks them by exposure.
For most insurers that ranking surfaces the same high-value targets. The member and broker portals, the claims and policy APIs, and the cloud storage behind them are where a breach does the most damage, so they earn the deepest testing.
Our guide to penetration testing for insurance companies breaks down that full stack.
Cadence follows the same logic. A system that changes weekly carries more accumulated risk between annual tests than one that never changes, which is the argument for testing continuously rather than once a year.
How CodeAnt AI Supports NAIC Model Law Penetration Testing Evidence
CodeAnt gives a risk-based program the testing depth and the documentation it needs to prove itself. It runs continuous, code-aware testing across the applications, APIs, and cloud the risk assessment flags, from both inside and outside the boundary.
On the application security requirement, its code-aware approach tests in-house applications as they are built, which maps directly to the model's secure-development language. Every finding ships with a working proof of exploit, a risk priority, and a retest, so the testing evidence is concrete rather than a policy statement.
Because testing runs on every change, the risk-ranked record stays current, which is what a regulator examining a risk-based program wants to see.
You can see the offensive side on the pentesting page. For the frameworks that cut across insurance, our compliance penetration testing guide covers SOC 2, PCI, and HIPAA.
Conclusion: Build Risk-Based Penetration Testing Evidence For NAIC Model 668
The NAIC Insurance Data Security Model Law does not name penetration testing as directly as NYDFS 23 NYCRR 500, but the practical requirement lands in the same place for insurers handling real policyholder data. A risk-based information security program must be able to show that systems are tested and monitored for actual and attempted attacks, not only protected by written policies.
For insurers, that means penetration testing should follow the risk assessment. Member portals, broker portals, claims APIs, payment flows, policy administration systems, cloud infrastructure, and externally developed applications should be tested based on the sensitivity of the data they touch and how often they change.
The cleanest approach for multi-state insurers is to build toward the stricter explicit NYDFS model, then use continuous testing to keep NAIC evidence current throughout the year. That creates a stronger record of scope, findings, exploit proof, remediation, and retesting.
Treat NAIC Model 668 penetration testing as a risk-based evidence program, not a one-time compliance task. Start with the applications and APIs that expose the most nonpublic information, validate real exploit paths, retest every fix, and maintain a live record that shows regulators your cybersecurity program is working as risk changes.
Launch a free black box scan for one URL to see what your risk assessment would flag first, then book a walkthrough to see continuous, code-aware testing that documents a risk-based program under Model 668. For the New York rule it is built on, read our NYDFS penetration testing requirements guide.
