Insurers sit on exactly what attackers want, dense files of personal, financial, and health data, and they run it through portals and APIs that change constantly. That combination is why penetration testing for insurance companies is both a regulatory requirement and a genuine risk-reduction need.
A modern insurer's security program is mostly invisible, running quietly across the stack. This guide covers the visible, testable part, what regulators require, what an insurance penetration test should actually cover, how often, and the specific flaws that put policyholder data at risk.
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, cloud, and external surface, producing the audit-ready evidence that NYDFS, GLBA, and the NAIC model law expect.
Which Regulations Require Penetration Testing For Insurance Companies?
Most insurers answer to more than one regulator, and several of those regulations point at penetration testing directly or through a risk assessment. The mix depends on where you operate and what lines you write.
Regulation | Applies to | Testing posture |
|---|---|---|
NYDFS 23 NYCRR 500 | NY-licensed insurers, agencies, brokers | Annual pentest, inside and outside, plus scans |
GLBA Safeguards Rule | Financial institutions incl. insurers (FTC) | Annual pentest or continuous monitoring, plus vuln assessment |
NAIC Model Law | Insurers in adopting states | Risk-based testing driven by the security program |
HIPAA | Health insurers and plans | Periodic evaluation, pentest is the accepted method |
PCI DSS | Anyone handling card payments | Annual pentest and after significant change |
The pattern is that annual is the floor almost everywhere, and the obligations stack rather than cancel. Being compliant with one does not exempt you from the others, though a single well-run program can satisfy several at once.
For the New York requirement in full, see our breakdown of NYDFS penetration testing requirements. For the frameworks that cut across every sector, our compliance penetration testing guide covers SOC 2, PCI, and HIPAA in depth.
What Should Insurance Penetration Testing Cover?
Scope is where insurance testing succeeds or fails. An insurer's attack surface is wider than a single web app, and the systems that hold the most sensitive data are often the ones added last to a test plan.
The core targets are the agent and broker portals, policy administration systems, claims and underwriting platforms, billing and payment flows, and the member portals and public APIs that expose them. Underneath sits the cloud infrastructure, where a single misconfiguration can undo the controls above it.
Every one of these touches nonpublic information, the policyholder PII, health records, and payment data the regulations are written to protect. A test that covers the marketing site but skips the claims API is testing the wrong thing.
Top Vulnerabilities Insurance Penetration Testing Should Find
The flaws that cause insurance breaches are rarely exotic. They cluster in a few categories, and knowing them is how you scope a test that finds real risk instead of noise.
Broken object level authorization, often called IDOR, is the standout. When a claims or policy endpoint returns a record without confirming the requester owns it, an attacker can enumerate other policyholders' data by changing an ID in the request.
Cloud misconfiguration is the second. An open storage bucket or an over-permissioned role can expose data directly, and it lives outside the application code where a surface-level scan will not look. Our guide to cloud penetration testing covers this layer.
Broken authentication rounds out the top three. Weak session handling or token validation on a broker portal turns one compromised account into access across the book of business. The theme across all three is authorization logic, which is precisely the class of bug that needs code context to find reliably.
How Often Do Insurance Companies Need Penetration Testing?
The regulations converge on a rhythm. NYDFS and the GLBA Safeguards Rule both set an annual floor, and NYDFS additionally requires scanning promptly after any material system change.
Annual works for a system that changes annually. Insurers do not fit that shape, since a single quarter can bring new API endpoints, a claims-system update, and a portal redesign, each capable of introducing an exposure the last test could not have seen.
This is the gap between the letter of an annual requirement and the reality of continuous delivery. It is also why the strongest programs test on every change rather than once a year, a point we cover in the comparison of continuous versus annual testing.
Why Annual Penetration Testing Leaves Gaps For Insurers
A once-a-year pentest produces a certificate and a false sense of coverage. The report is accurate on the day it is written and starts aging with the next deployment.
For a regulated insurer, that aging is a compliance problem as much as a security one. When an examiner asks what changed since the last test and how it was validated, an annual snapshot has no answer for the eleven months in between.
Continuous testing closes that window by re-examining the surface as it changes and keeping a live record of findings, fixes, and retests. That record is the same evidence the annual certification asks for, produced as a byproduct rather than reconstructed under deadline.
How CodeAnt AI Supports Continuous Insurance Penetration Testing
CodeAnt tests an insurer's stack the way the regulations describe it, from both inside and outside the boundary, as a continuous system. From outside it maps the exposed portals, APIs, and services an adversary would probe. From inside it reads the application code and cloud configuration to find the authorization gaps and misconfigurations an external scan misses.
Because it is code-aware, it catches the broken object level authorization on a claims API by identifying the endpoints that never check ownership, rather than blindly fuzzing IDs. Findings arrive with a working proof of exploit, a risk priority, and a retest, mapped to the control they satisfy.
The outcome is a program that stays current between annual tests and generates certification-ready evidence for NYDFS, GLBA, and the NAIC model law in one pass. You can see the offensive side on the pentesting page, and compare depth against cost in our penetration testing cost guide.
Conclusion: Build Continuous Penetration Testing Evidence For Insurers
Penetration testing for insurance companies stacks several requirements on top of each other, NYDFS, GLBA, the NAIC model law, and HIPAA or PCI depending on your lines. They converge on an annual floor, a scope that spans every portal and API touching policyholder data, and a demand for evidence that a fix actually held.
If your insurance stack includes broker portals, claims APIs, payment flows, or cloud-hosted policyholder data, start with one high-risk surface. Run an outside-in assessment to see what an adversary can reach, then move toward continuous, code-aware penetration testing that keeps NYDFS, GLBA, NAIC, HIPAA, and PCI evidence current throughout the year.
That is the model CodeAnt runs. Launch a free black box scan for one URL to see what an adversary can reach in your stack, then book a walkthrough to see continuous, code-aware insurance penetration testing mapped to NYDFS, GLBA, and the NAIC model law. For the New York specifics, start with our NYDFS penetration testing requirements guide.
