The 2026 Cobalt State of Pentesting report profiles financial services and insurance with a conclusion that should prompt every CISO in the industry to look twice. Both sectors test with discipline. Both are programmatic, measured, and confident about their programme design. Both have a specific blind spot that sits in plain sight once the data is laid out.
Financial services and insurance test AI applications more than any other sector, and have fewer AI incidents as a result. But they expand red teaming the least of any industry surveyed. Their remediation time sits mid-pack despite the regulatory sophistication and testing volume that characterises both sectors.
That combination is not a contradiction. It is what happens when compliance drives a testing programme and threat simulation does not keep pace with it.
Disciplined Testing Volume With a Structural Limit
The financial services and insurance sectors do not have a frequency problem. Both test regularly. Both treat penetration testing as a programme, not an event. Regulatory frameworks create that discipline: PCI DSS requires annual testing and has for years, GLBA mandates annual penetration tests and semiannual scans under the updated Safeguard Rule, and NYDFS 23 NYCRR 500 requires annual penetration testing for New York-regulated financial entities. In Australia, APRA CPS 234 mandates that regulated entities test the effectiveness of their information security controls at a frequency commensurate with their threat exposure. RBNZ guidance for New Zealand banks and insurers carries equivalent expectations.
The compliance calendar drives coverage. Compliance-driven testing tends to reproduce the same scope, methodology, and surface area each year. Regulators ask whether testing happened. They ask less often whether the programme is evolving with the threat environment. The result is a sector that tests consistently but remediates with moderate speed rather than urgency, because the programme was designed to satisfy audit requirements rather than to move faster than adversaries.
AI Testing Leadership and What It Means
The Cobalt finding that financial services and insurance test AI applications more than any other sector reflects genuine risk awareness. Financial institutions deploy AI across fraud detection, credit decisioning, claims processing, and authentication faster than most industries. They know adversarial inputs to AI models can exploit systems in ways traditional testing frameworks were not built to catch.
Testing AI applications more than any other sector is the right decision. It is also, in the context of the remediation ranking, a revealing one. The sector leading on AI security testing is still remediating at mid-pack speed. That gap suggests finding vulnerabilities is not the constraint. Acting on them is. Cyber insurance carriers have noticed. They now require evidence not just that testing happened, but that findings were remediated within specific windows. Annual testing with mid-pack remediation speed is a combination carriers are beginning to price into premiums. As analysed in the sector-specific guide to the state of pentesting in financial services and insurance regulatory context, the average breach detection time of 168 days in financial services means the remediation window is often running during an active compromise, not before it.
Your Last Pentest Is Already Out of Date
Every week you ship without continuous testing is a week a vulnerability goes unseen. See what Capture The Bug finds in your first engagement.
The Red Teaming Gap
Expanding red teaming the least of any surveyed industry is the most operationally significant finding in the Cobalt report for programme designers. Red teaming is not a compliance checkbox. No major framework mandates red team exercises the way frameworks mandate penetration testing. Red teaming is what organisations do when they want to know whether their detection and response capabilities would hold against an attacker not constrained by a scope document.
Sectors that expand red teaming have concluded that their detection and response capability is the variable most in need of testing. Sectors that do not expand red teaming concentrate investment in compliance-satisfying tests that generate findings but do not simulate the multi-stage, long-dwell campaigns that characterise the actual threats financial institutions face.
Ransomware groups target the sector for payment capacity. Nation-state actors target it for financial data and market intelligence. Both operate over extended dwell periods. A testing programme that covers vulnerability discovery but does not simulate adversary behaviour after initial access is testing the entry point without testing the house.
What a Programme Looks Like That Addresses All Three
The Cobalt data suggests three adjustments for financial sector leaders in NZ, AU, and the USA.
First, remediation velocity needs its own metric. Testing frequency and finding closure speed are different disciplines. Building SLA-based remediation tracking and reporting it separately from test completion is what shifts mid-pack remediation to front-of-pack.
Second, red team exercises should run on a cadence that reflects the threat model, not the compliance calendar. Annual penetration testing satisfies the regulator. A red team exercise answers a different question: would we know if someone was inside, and how fast would we respond? Continuous penetration testing for SOC 2 and ISO 27001 compliance covers how continuous validation creates the real-time evidence base that compliance programmes increasingly expect.
Third, AI testing leadership needs to connect to the remediation programme. Finding AI vulnerabilities faster than any other sector but closing them at mid-pack speed addresses the gap in the wrong place. The guide to what happens after a penetration test covers the verification process that turns findings into confirmed closures.
Financial services and insurance run security like the regulated sectors they are. The data's message is not that they need to test more. It is that testing programmatically without advancing response and simulation leaves the programme behind the threats it is designed to address.
Book a security consultation with Capture The Bug to benchmark your current testing programme against what the 2026 sector data and your specific regulatory framework require.
Plan Your Annual Pentesting Strategy the Right Way
Learn how modern SaaS companies structure pentesting across the year to reduce risk, stay compliant, and avoid last-minute panic before audits.
FAQ
What does the 2026 state of pentesting data show about financial services and insurance testing programmes?
The 2026 Cobalt State of Pentesting report found that financial services and insurance test AI applications more than any other sector and have fewer AI incidents as a result. However, they expand red teaming the least of any industry surveyed, and their remediation time sits mid-pack despite high testing volume. The pattern reflects compliance-driven testing discipline without equivalent advancement in threat simulation or remediation velocity.
Why do financial services and insurance companies expand red teaming the least of any industry?
Red teaming is not mandated by major regulatory frameworks in the same prescriptive way that penetration testing is required under PCI DSS, GLBA, or NYDFS. Financial sector testing investment tends to concentrate on compliance-satisfying annual penetration tests. Red teaming addresses a different question: whether detection and response capabilities would hold against a multi-stage, long-dwell campaign. Sectors that expand red teaming have typically concluded that their response capability is the variable most in need of testing.
How often do financial services companies need to do penetration testing to meet compliance requirements?
Requirements vary by framework. PCI DSS requires annual penetration testing. GLBA requires annual penetration tests and semiannual scans under the updated Safeguard Rule. NYDFS 23 NYCRR 500 requires annual penetration testing for New York-regulated financial entities. In Australia, APRA CPS 234 requires testing at a frequency commensurate with threat exposure. RBNZ guidance in New Zealand carries equivalent expectations for registered banks and licensed insurers. Industry best practice, particularly for organisations running continuous deployment cycles, recommends testing frequency that reflects the pace of environmental change rather than the compliance calendar.
What is remediation lag and why does it matter in financial services?
Remediation lag is the gap between when a vulnerability is found in a penetration test and when it is confirmed as closed. In financial services, the Cobalt 2026 data places the sector mid-pack on remediation speed, despite leading on testing frequency and AI security investment. Remediation lag matters because the average breach detection time in financial services is 168 days. A finding that sits unresolved for weeks or months after a test creates a window that overlaps with dwell time for attackers who are already inside the environment.
How should ANZ financial institutions approach their security testing programme in 2026?
ANZ financial institutions should treat testing frequency and remediation velocity as separate, separately measured disciplines. Compliance frameworks like APRA CPS 234 and RBNZ guidance require testing commensurate with threat exposure, which in 2026 means annual testing alone is insufficient for organisations running regular deployments. Red team exercises should be added on a cadence that reflects the threat model rather than the compliance calendar. AI security testing leadership should be paired with explicit SLA- based remediation tracking to convert findings into confirmed closures.
