In April, a single VPN vulnerability led to data breaches at more than seventy financial institutions running Marquis Software’s infrastructure, according to American Banker’s reporting on the incident. The patch existed. The institutions affected likely had recent penetration tests on file. Neither prevented the exposure from compounding across the portfolio.
The math is straightforward. A standard annual external penetration test runs two to three weeks of active testing. That leaves roughly 345 days of operational reality unvalidated.
Mandiant’s M-Trends 2026 report puts the 2025 median dwell time at fourteen days, reversing a multi-year decline, with espionage actors averaging 122-days.
CrowdStrike’s 2026 Global Threat Report ranks financial services fourth in interactive intrusion targeting. Adversaries did not wait between annual assessments. The model assumed they would.
Regulators Set the Floor Against a Slower Threat Model
PCI DSS, FFIEC, and NYDFS all reference penetration testing in their requirements and guidance. None of them describe annual cadence as sufficient.
PCI DSS 4.0 Requirement 11.3.1 mandates external penetration testing after any significant infrastructure or application upgrade or modification. The FFIEC IT Examination Handbook describes penetration testing as part of ongoing vulnerability management, not a discrete annual event. NYDFS Section 500.05 mandates annual testing alongside continuous monitoring obligations strengthened in the 2023 amendments to 23 NYCRR 500.
Every one of these frameworks already assumes testing happens in response to change. The regulatory floor was written for institutions where significant changes happened on quarterly release cycles.
That cadence does not match modern banking infrastructure. Digital banking releases, cloud workload migrations, fintech API integrations, third-party portal launches, and M&A integration work all generate untested attack surface between annual tests.
The compliance question is no longer whether the institution tested last year. It is whether the institution tested the things that actually changed.
Financial institutions run on change from cloud migrations, fintech integrations, and M&A. Your attack surface doesn’t wait for the next engagement.
See how continuous testing closes the gap regulators already expect you to close.
What the Gap Produces, Documented
In a recent engagement at a regional bank, Sprocket testers identified a finding on a customer-facing mortgage origination portal the bank fronts at a subdomain it owns. The portal is operated by a third-party platform vendor, with the bank’s brand and hostname presented to applicants. The asset was in scope for external testing.
The platform exposed an API endpoint that returned organization records when given a tenant ID. The endpoint required no authentication and no session of any kind. The platform’s cross-origin policy allowed any third-party site to invoke the same request from a visitor’s browser without user interaction.
The tenant ID itself was visible in the portal’s own public-facing files, so an unauthenticated caller did not need to guess it. Incrementing the tenant ID by one returned the records for the next institution on the shared platform. Iterating through the range surfaced records for every financial institution running on the platform, plus the vendor’s own internal tenant.
The records returned were not generic. Each one contained named staff with business email addresses, direct-dial phone numbers, job titles, and an internal code the platform used to attribute borrower submissions to specific personnel.
That code was significant on its own: any caller in possession of a valid code could submit a prospective borrower application in a named officer’s name against that officer’s institution, and the platform would treat the submission as legitimate intake into the loan-origination pipeline.
The bank did not introduce this exposure. The platform vendor did. The bank’s previous annual external assessment may have covered the hostname in scope at the time of testing, but no automated scanner surfaces this finding.
Catching it required walking sequential tenant IDs against an undocumented endpoint and validating that the records returned belonged to other institutions, and it had to run against the production deployment.
The downstream risk is what makes the finding regulatory in nature, not just technical. Data belonging to every other institution on the shared platform was extractable through the bank’s hostname.
Any fraud, phishing, or compliance incident that followed from that exposure would route to the institution named in the URL, regardless of which tenant’s data the attacker actually used.
Continuous Testing Is the Operational Answer to the Engagement Above
The finding above gets largely overlooked in an annual model. Three reasons, each tied directly to the engagement.
The asset entered the bank’s external footprint when the vendor onboarded the bank to the platform, not when the bank’s pentest was scoped. If the engagement scope was set against a snapshot of infrastructure from six months earlier, the hostname might not have been listed. Attack surface management closes this gap by treating new hosts and new exposed services as testing triggers, not by waiting for the next annual scope conversation.
The asset was also the kind of thing institutions routinely exclude from annual scope. Vendor-operated portals fronted at the institution’s own subdomain occupy a gray zone in scoping conversations.
They are not the bank’s application, the bank does not have source code, the bank does not control releases, and the vendor maintains its own security program.
Institutions reasonably decide the platform vendor is responsible for testing its own code and exclude the hostname from the engagement. Continuous external reconnaissance does not honor that boundary.
If the hostname is reachable on the open Internet under a domain the bank owns, it is part of the bank’s external attack surface, and an attacker enumerating the bank’s perimeter will encounter it whether or not the bank’s most recent scope document listed it.
The finding also required active human testing, not scanner output. A vulnerability scanner sweeping the hostname would have reported the endpoint as responsive and the CORS policy as permissive, possibly flagged the missing authentication header, and stopped there.
It would not have walked tenant IDs, validated cross-tenant data return, or chained the staff-attribution code into a submission-forgery scenario. Automation surfaces possibilities. Testers establish what is actually exploitable, and what the downstream impact is when it is.
Sprocket Security operates the continuous model on this principle. The attestation that follows reflects what was tested against the infrastructure that existed when the test ran, not a snapshot from twelve months earlier.
The Gap Is Structural, Not a Cadence Problem
The 345-day gap is not a marketing number. It is a structural feature of the annual testing model. Regulators wrote testing requirements assuming institutions would test the things that changed, when they changed.
Most institutions test what existed at the time of the engagement, on the schedule the engagement was scoped for, and treat the resulting attestation as a description of current exposure. That description gets less accurate every day after the test concludes.
The institutions that close the gap are not the ones that test more often. They are the ones whose testing program responds to what their infrastructure actually does.
See how you can build your case for continuous testing in the financial space today.
Sponsored and written by Sprocket Security.
