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.
Insurers also sit on both sides of cyber risk. The cyber insurance requirements they set for policyholders, such as MFA and regular testing, increasingly apply to their own security programs.
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 FTC rule, see our breakdown of GLBA penetration testing requirements, and for adopting states, the NAIC Insurance Data Security Model Law guide.
For the frameworks that cut across every sector, our compliance penetration testing guide covers SOC 2, PCI, and HIPAA in depth.
Penetration Testing by Line of Insurance
Every line of insurance runs on different systems, so the attack surface shifts with the business you write. Here is what a pentest should focus on for each one.
Health and Dental Payers
Payers expose claims, eligibility, and clinical data through member portals and FHIR APIs required by CMS interoperability rules. Clearinghouse connections add a third-party path into the same data. HIPAA applies in full, so every API that returns PHI needs object-level authorization testing. This guide builds on our broader look at penetration testing for insurers.
Life and Annuity
Life carriers run long-lived policy administration systems behind modern agent portals and third-party CRMs. The highest-risk flows are beneficiary changes, loans, and surrenders, where an account takeover turns directly into a redirected payout. For the regulations every carrier shares, start with our insurance pentesting guide.
Auto and Home
Personal lines carriers depend on quote engines and prefill APIs that pull driver's license and vehicle data from outside sources. Quote tools that returned that data to anyone who asked have already drawn New York enforcement. Telematics feeds and claims photo uploads widen the surface further. This piece covers personal lines specifically, and the pentest requirements across insurance apply here too.
Commercial and MGAs
Commercial carriers receive submissions through broker portals that accept document uploads from many outside firms. MGAs bind policies under delegated authority, so a flaw in the MGA's platform can expose the carrier's book. Testing needs to cover file upload handling and tenant isolation between brokers.
Workers' Comp
Workers' comp carriers and TPAs combine medical records with employer payroll data, often outside HIPAA's direct scope. Employer portals, payroll integrations, and adjuster access to treatment records are the core test targets. Workers' comp sits partly outside HIPAA, so the rules in penetration testing for insurance companies do most of the work.
Specialty Lines
Medical and legal malpractice carriers hold privileged claim files that carry legal as well as privacy risk. Aviation, marine, and crop insurers exchange data with market platforms, brokers, and federal program systems. Every one of those partner connections belongs in scope. Specialty lines add partner systems on top of the controls in how insurers approach penetration testing.
Agencies and Brokers
Small agencies often qualify for limited exemptions under NYDFS and the NAIC model law, but larger brokers face the full requirements. One compromised agent login can reach several carrier portals at once. That makes credential handling and agency management systems the priority. Agencies inherit many of the same insurance-wide pentest requirements as the carriers they write for.
Title and Escrow
Title and escrow companies deliver closing documents through web links, and predictable document IDs have exposed hundreds of millions of records in the past. Wire instructions make these firms a steady target for business email compromise. ALTA Best Practices Pillar 3 sets the baseline for data security.
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. Our API penetration testing guide covers how to test the claims and policy APIs underneath them.
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 cloud pentesting guide for AWS, Azure, and GCP 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.
Recent Insurer Breaches, Analyzed
The same flaws covered above show up in real incidents across the industry. Each breakdown below walks through the attack path and the test that would have caught it.
Change Healthcare (2024). Stolen credentials on a remote-access portal without MFA led to the Change Healthcare remote-access ransomware attack, affecting about 192.7 million people.
Delta Dental of California (2023). The Delta Dental MOVEit breach used a zero-day in a file transfer tool to expose data on roughly 7 million people.
Aflac (2025). The Aflac social engineering breach, linked to Scattered Spider, exposed Social Security numbers and claims data for 22.65 million people.
Farmers Insurance (2025). The Farmers Insurance Salesforce breach began with voice phishing against a third-party CRM and exposed about 1.1 million customers.
Fidelity National Financial (2023). The Fidelity National Financial ransomware attack disrupted title and closing operations and affected about 1.3 million customers.
Anthem (2015). The Anthem phishing breach exposed records of 78.8 million people and ended in a $16 million OCR settlement.
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. To compare vendors side by side, see our best penetration testing tools for insurance guide. For platforms serving several carriers, the insurtech NYDFS and SOC 2 guide covers tenant isolation.
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.
