Insurance companies sit on some of the richest nonpublic data in the United States: Social Security numbers, medical histories, claims records, banking details, and beneficiary information. Two regulatory frameworks shape how that data must be defended and, critically, how often it must be attacked by your own side first. The first is New York's 23 NYCRR Part 500, enforced by the New York Department of Financial Services (NYDFS). The second is the NAIC Insurance Data Security Model Law, known as Model 668, which individual states adopt into their own insurance codes.
These two frameworks are frequently named in the same breath, but they treat penetration testing very differently. One names it explicitly and sets a hard cadence. The other never uses the words at all and ties the obligation to your risk assessment. If you run security or compliance for a carrier, an MGA, a TPA, or an insurtech, you need to understand both, because the gap between them is where audit findings live.
NYDFS 23 NYCRR Part 500 was first enacted in 2017 and significantly tightened by the Second Amendment, which NYDFS finalized on November 1, 2023. The penetration testing language lives in Section 500.05, titled Vulnerability Management.
The amended rule is specific. Covered entities must conduct penetration testing of their information systems from both inside and outside the systems' boundaries by a qualified internal or external independent party at least annually. The amendment also requires automated scans and a manual review of systems not covered by those scans, at a frequency set by the risk assessment and after any material change to the environment. The penetration testing obligation under the Second Amendment became effective on November 1, 2024, so carriers operating in New York are now firmly inside the enforcement window.
Three words in that clause carry most of the weight. "Both inside and outside" means an external-only test does not satisfy the rule. "Qualified independent party" means the tester cannot be the person who built or administers the system. "At least annually" sets a floor, not a ceiling, and the risk assessment can push you to test more often. Independent, boundary-spanning validation is exactly the kind of engagement Redfox Cybersecurity structures around the 500.05 clause so the evidence maps cleanly to the regulation.
Here is the honest answer that many compliance summaries get wrong. The NAIC Insurance Data Security Model Law, adopted in October 2017 and now enacted in some form across roughly two dozen states, never uses the phrase "penetration testing" and sets no annual cadence.
What Model 668 does require is a comprehensive written information security program built on a documented risk assessment. The licensee must assess the effectiveness of key controls, systems, and procedures no less than annually, and must regularly test and monitor systems to detect actual and attempted attacks. Penetration testing is one of the clearest, most defensible ways to meet that "regularly test" obligation, but the model leaves the intensity and frequency to your own risk assessment rather than dictating it.
That risk-based structure is a double-edged sword. It gives smaller licensees flexibility, but it also means a regulator or plaintiff's attorney can argue that your risk assessment should have called for testing you never performed. When the standard is "reasonable for your risk," thin evidence becomes a liability. A risk-driven testing program that produces defensible artifacts is where many insurers need help, and it is a core part of what Redfox Cybersecurity delivers for carriers operating under state Model 668 regimes.
The two frameworks converge on the same practical outcome for any insurer handling real policyholder data, but the path differs.
NYDFS Part 500 is prescriptive. It names penetration testing, requires independence, mandates internal and external coverage, and fixes an annual minimum. A New York examiner can point to 500.05 and ask for last year's report. The annual compliance certification is signed by the CEO or highest-ranking executive, which puts personal accountability behind the program.
The NAIC Model Law is principles-based. It demands a program and testing proportionate to risk, but it hands you the pen to define the scope. For a multi-state carrier, the safe design is to build to the stricter New York standard and apply it across the enterprise, because a single annual, independent, internal-and-external test satisfies both the explicit NYDFS requirement and the implicit NAIC one. Designing one testing program that clears both bars at once avoids duplicate spend and inconsistent evidence.
Scope is the first place engagements go wrong. The regulation says "information systems," which for an insurer typically includes the external perimeter, the internal corporate and claims networks, the policyholder and agent portals, the quote and binding APIs, and the cloud tenancy hosting nonpublic information. Subsidiaries and acquired books of business are frequently missed and are frequently where the weakest controls live.
Before any tooling runs, lock down the authorization boundary, the IP ranges, the API endpoints, the test accounts, and the rules of engagement in writing. For insurers, that document is itself compliance evidence, because it demonstrates the test was scoped against the systems identified in the risk assessment. With scope agreed, the technical work proceeds in layers.
External testing proves what an unauthenticated internet attacker can reach. For insurers this surface is usually broker portals, mail gateways, VPN concentrators, and legacy claims apps that were never meant to face the internet.
Start with a full-port discovery sweep, then fingerprint services and run template-driven checks for exposed panels and known CVEs.
# External attack surface sweep against the in-scope insurance ranges
nmap -sS -Pn -p- --min-rate 3000 -oA ext_full 203.0.113.0/24
# Service and version fingerprinting on the discovered ports
nmap -sV -sC -p 443,8443,3389,25,587,1194 -oA ext_services -iL live_hosts.txt
# Template-driven checks for exposed panels, CVEs, and misconfigurations
nuclei -l live_hosts.txt -t http/exposed-panels/ -t http/cves/ -severity high,critical -o nuclei_ext.txt
[cta]
The findings that matter most to an insurer are exposed administrative interfaces, VPN or RDP gateways missing multifactor authentication, and outdated web front ends on claims systems. Each of these maps directly to a nonpublic information exposure story, which is the language NYDFS and state examiners respond to. Reporting a critical CVE is table stakes; tying it to the specific policyholder data it exposes is what makes the report defensible.
Insurance portals almost always expose a login. Test for credential reuse, weak password policies, missing account lockout, and authentication bypass before assuming the portal is safe because it prompts for a password. Password spraying against an exposed portal, done carefully and within the agreed rules of engagement, often reveals a single reused credential that unlocks the whole claims workflow.
NYDFS explicitly requires testing from inside the boundary, and this is where most insurers discover their real exposure. The assumed-breach model, where the tester starts with a standard domain foothold or a single set of low-privilege credentials, mirrors how ransomware actually spreads through a carrier's network.
The first moves on an internal engagement are name-resolution poisoning, careful password spraying, and attack-path mapping across Active Directory.
# Capture NetNTLMv2 hashes from broadcast poisoning on the internal VLAN
sudo responder -I eth0 -wvF
# Spray one password across the domain without tripping lockout thresholds
nxc smb 10.10.0.0/24 -u users.txt -p 'Autumn2026!' --continue-on-success
# Collect AD relationships for attack-path analysis
bloodhound-python -d insurer.corp -u svc_scan -p 'REDACTED' -ns 10.10.0.10 -c All
# Hunt for vulnerable certificate templates (ESC1 through ESC8)
certipy find -u svc_scan@insurer.corp -p 'REDACTED' -dc-ip 10.10.0.10 -vulnerable
[cta]
BloodHound turns a flat list of accounts into a graph of who can reach Domain Admin and how. In insurance environments, the shortest path usually runs through an over-privileged service account tied to a policy administration system or a claims batch job. Certipy surfaces Active Directory Certificate Services misconfigurations, which have become one of the most reliable privilege-escalation routes in enterprise networks. If your internal directory has never been attacked from an assumed-breach position, Redfox Cybersecurity runs exactly this kind of internal engagement and documents each path for remediation.
Kerberos abuse is high-signal for both attackers and examiners because it exposes weak service-account hygiene. Enumerate users, pull AS-REP roastable accounts that lack pre-authentication, and request service tickets for offline cracking.
# Enumerate valid domain users before any authenticated access
kerbrute userenum -d insurer.corp --dc 10.10.0.10 users.txt
# Pull AS-REP roastable hashes for accounts without Kerberos pre-auth
impacket-GetNPUsers insurer.corp/ -usersfile valid_users.txt -no-pass -format hashcat -outputfile asrep.hash
# Request SPN tickets for offline cracking (Kerberoasting)
impacket-GetUserSPNs insurer.corp/svc_scan:'REDACTED' -dc-ip 10.10.0.10 -request -outputfile spn.hash
[cta]
Any hash recovered here proves a concrete control failure: a service account with a weak, crackable password and no rotation. That is precisely the kind of finding a risk assessment is supposed to catch and a penetration test is supposed to validate. Cracking the recovered material closes the loop and demonstrates real-world exploitability rather than theoretical risk.
# Crack captured AS-REP and Kerberoast hashes to prove weak credentials
hashcat -m 18200 asrep.hash rockyou.txt -r best64.rule
hashcat -m 13100 spn.hash rockyou.txt -r best64.rule
[cta]
When a service-account password falls in minutes, the report writes itself: the control the risk assessment assumed was in place does not actually hold. That evidence is far more persuasive to a board and a regulator than a vulnerability scanner's severity rating.
Policyholder and agent portals are the systems most directly tied to nonpublic information, so they deserve dedicated application testing beyond a network scan. The common failure modes in insurance apps are broken object-level authorization, where one policyholder can read another's policy by changing an ID, and injection flaws in quote and claims endpoints.
Begin with content discovery to find hidden administrative and API routes, then test the exposed endpoints for injection using an authenticated session.
# Content discovery against the policyholder portal
ffuf -u https://portal.insurer.com/FUZZ -w raft-medium-directories.txt -mc 200,301,302,401,403 -o ffuf_portal.json
# Test the quote API for injection using an authenticated session cookie
sqlmap -u "https://portal.insurer.com/api/quotes?policyId=1001" \
--cookie="session=eyJhbGciOi..." --level 3 --risk 2 --batch --dbs
[cta]
The highest-impact test on an insurance portal is manual authorization testing in a proxy such as Burp Suite Professional. Log in as policyholder A, capture a request for their own policy, then replay it with policyholder B's identifier. If the record comes back, you have a broken access control issue that exposes nonpublic information at scale, which is the exact harm both NYDFS and the NAIC Model Law exist to prevent. Thorough application and API testing of these portals is a focus area for Redfox Cybersecurity, because this is where a single logic flaw can expose an entire book of policyholders.
A penetration test is only as useful as the evidence it produces. For an insurer, the deliverable has to do double duty as a security roadmap and a compliance artifact. Examiners and auditors look for a defined scope tied to the systems named in your risk assessment, proof that testing covered inside and outside the boundary, confirmation that the tester was a qualified independent party, findings rated by real business impact rather than raw CVSS, and a remediation record showing issues were fixed and retested.
The retest point is often overlooked. NYDFS vulnerability management expects remediation, not just discovery. A report that lists twenty critical findings with no evidence of closure can be worse than no report, because it documents known, unaddressed risk. Strong engagements include a retest phase and a clear mapping of each finding back to the specific regulatory clause it touches, whether that is 500.05 for New York or the risk-assessment and testing provisions of your state's Model 668 statute.
Under NYDFS Part 500, the answer is clear: penetration testing at least annually, covering internal and external, plus vulnerability scanning at a frequency driven by your risk assessment and triggered again after material changes. A cloud migration, a merger, a new claims platform, or an acquired subsidiary all count as material changes that should trigger fresh testing rather than waiting for the annual cycle.
Under the NAIC Model Law, there is no fixed number. The cadence is whatever your risk assessment can justify. In practice, an annual full-scope test plus event-driven testing after major changes is the defensible baseline, and it conveniently matches the NYDFS floor. Carriers that operate in New York and in Model 668 states should simply adopt the annual-plus-material-change rhythm everywhere to keep one consistent standard across the enterprise.
The most efficient compliance posture for a US insurer treats NYDFS Part 500 as the design target and the NAIC Model Law as a confirmation that the same program is reasonable for risk in every other state. That means scoping to the full information system including subsidiaries, running annual internal and external penetration tests with a qualified independent party, layering continuous or risk-based scanning underneath, testing policyholder-facing applications and APIs for authorization and injection flaws, and retesting to prove remediation.
Done well, a single program generates the independent report NYDFS names in 500.05, the evidence of regular testing the NAIC Model Law expects, and the kind of board-level assurance that a CEO can certify without hesitation. Done poorly, you end up with scanner output that satisfies neither framework and leaves nonpublic information exposed. If you want that program designed, executed, and documented against the exact clauses your examiners cite, Redfox Cybersecurity builds insurance penetration testing engagements for precisely that outcome.
NYDFS Part 500 names penetration testing outright: internal and external, independent, at least annually, with scanning and material-change testing underneath. The NAIC Model Law never says the words but lands in the same place through its risk assessment and regular-testing mandate, with the cadence left to you. For any carrier, MGA, TPA, or insurtech handling policyholder data, the smart move is to build to the stricter New York standard and apply it enterprise-wide, so one well-scoped annual test and its evidence trail clear both bars. The tooling is only half the job. What protects an insurer under examination is testing that reaches inside and outside the boundary, maps each finding to the data it exposes and the clause it touches, and proves the fixes actually held.
Redfox Cyber Security Inc.
8 The Green, Ste. A,
Dover, Delaware 19901,
United States.
.avif)