Back in April, a single VPN flaw opened the door to data breaches at over 70 financial institutions that relied on Marquis Software’s infrastructure. American Banker covered the story in detail. A fix was available. The impacted institutions probably had up-to-date penetration test reports on hand. Yet none of that stopped the damage from spreading across the entire portfolio.
The numbers tell the story clearly. A typical annual external penetration test involves about two to three weeks of hands-on testing. That means roughly 345 days of real-world operations go completely unchecked.
Mandiant’s M-Trends 2026 report shows the 2025 median dwell time climbed back up to 14 days, breaking a years-long downward trend, with espionage-focused attackers lingering for an average of 122 days.
CrowdStrike’s 2026 Global Threat Report places financial services as the fourth most targeted sector for interactive intrusions. Attackers didn’t sit around waiting for the next yearly assessment. The traditional testing model, however, was built on the assumption that they would.
Regulators Set the Floor, but the Threat Landscape Moves Faster
PCI DSS, FFIEC, and NYDFS all mention penetration testing in their requirements and guidance. None of them treat an annual schedule as adequate on its own.
PCI DSS 4.0 Requirement 11.3.1 requires external penetration testing following any major infrastructure or application change. The FFIEC IT Examination Handbook frames penetration testing as a component of continuous vulnerability management rather than a once-a-year checkbox. NYDFS Section 500.05 calls for annual testing but pairs it with continuous monitoring requirements that were reinforced in the 2023 updates to 23 NYCRR 500.
All of these frameworks already operate on the premise that testing should happen whenever something changes. The regulatory baseline was designed for an era when meaningful changes rolled out on quarterly cycles.
That pace no longer reflects how modern banking works. Digital banking updates, cloud workload shifts, fintech API rollouts, third-party portal deployments, and merger-related integration efforts all create fresh, untested attack surface between annual assessments.
The real compliance question has shifted. It’s no longer about whether the institution ran a test last year. It’s about whether the institution tested the things that actually changed.
Financial institutions are constantly evolving through cloud migrations, fintech partnerships, and mergers. Your attack surface doesn’t pause for the next scheduled engagement.
Discover how continuous testing closes the gap that regulators already expect you to address.
Build the Business Case
What the Gap Looks Like in Practice
During a recent project at a regional bank, Sprocket’s testing team uncovered a vulnerability on a customer-facing mortgage origination portal that the bank hosted at one of its own subdomains. The portal was run by a third-party platform vendor, displaying the bank’s branding and hostname to applicants. The asset fell within the scope of external testing.
The platform had an API endpoint that handed over organization records whenever someone supplied a tenant ID. The endpoint demanded no authentication whatsoever, not even a session token. On top of that, the platform’s cross-origin policy let any external website trigger the same request through a visitor’s browser without any action on the user’s part.
The tenant ID itself was sitting in the portal’s publicly accessible files, so an attacker didn’t need to guess anything. Bumping the tenant ID up by one pulled the records for the next institution on the shared platform. Cycling through the full range exposed data for every financial institution using the platform, including the vendor’s own internal tenant.
The data returned wasn’t vague or generic. Each record included staff members’ names, business email addresses, direct phone numbers, job titles, and an internal identifier the platform used to tie borrower submissions to specific employees.
That identifier carried serious implications on its own: anyone with a valid code could file a prospective borrower application under a named officer’s identity at that officer’s institution, and the platform would accept it as a legitimate entry into the loan origination workflow.
The bank didn’t create this vulnerability. The platform vendor did. The bank’s prior annual external assessment might have included the hostname at the time of testing, but no automated scanner would flag this kind of issue.
Finding it meant manually stepping through sequential tenant IDs against an undocumented endpoint, confirming that the returned records belonged to other institutions, and running the test against the live production environment.
The downstream consequences are what elevate this from a technical finding to a regulatory concern. Data belonging to every other institution on the shared platform was accessible through the bank’s own hostname.
Any fraud, phishing campaign, or compliance fallout stemming from that exposure would land on the institution named in the URL, no matter which tenant’s data the attacker actually exploited.
Continuous Testing Is the Practical Response
The finding described above would almost certainly slip through the cracks in an annual testing model. There are three reasons, each directly tied to the engagement.
First, the asset became part of the bank’s external footprint when the vendor onboarded the bank onto the platform, not when the bank’s penetration test was being planned. If the engagement scope was based on an infrastructure snapshot from six months prior, the hostname might not have made the list. Attack surface management addresses this by treating new hosts and newly exposed services as triggers for testing, rather than waiting for the next annual scoping discussion.
Second, this is exactly the type of asset that institutions routinely leave out of annual testing scope. Vendor-operated portals hosted at the institution’s own subdomain sit in a gray area during scoping conversations.
It’s not the bank’s application. The bank doesn’t have access to the source code. The bank doesn’t control deployments. And the vendor runs its own security program.
It’s reasonable for institutions to conclude that the platform vendor is responsible for testing its own code and to exclude the hostname from the engagement. Continuous external reconnaissance doesn’t respect that boundary.
If the hostname is reachable on the public internet under a domain the bank owns, it’s part of the bank’s external attack surface, and an attacker mapping the bank’s perimeter will find it regardless of whether the bank’s latest scope document included it.
Third, the finding demanded hands-on human analysis, not scanner output. A vulnerability scanner sweeping the hostname would have noted that the endpoint responded, flagged the permissive CORS policy, and possibly called out the missing authentication header, then moved on.
It wouldn’t have walked through tenant IDs, confirmed cross-tenant data leakage, or connected the staff-attribution code to a submission forgery attack chain. Automation highlights possibilities. Skilled testers determine what’s genuinely exploitable and what the real-world impact looks like when it is.
Sprocket Security’s continuous model is built on exactly this principle. The resulting attestation reflects what was tested against the infrastructure as it existed at the time of testing, not a snapshot from a year ago.
The Gap Is Built Into the Model, Not the Schedule
The 345-day gap isn’t a figure pulled from thin air for marketing purposes. It’s a structural reality of the annual testing approach. Regulators wrote their testing requirements expecting institutions to test the things that changed, at the time they changed.
Most institutions test what was in place when the engagement ran, on the timeline the engagement was scoped for, and then treat the resulting attestation as an accurate picture of current risk. That picture grows less reliable with every passing day after the test wraps up.
The institutions that successfully close the gap aren’t necessarily the ones testing more frequently. They’re the ones whose testing programs adapt to what their infrastructure is actually doing.
Explore how to make the case for continuous testing in the financial sector today.
Sponsored and written by Sprocket Security.
