A single unpatched VPN vulnerability was enough to compromise data across more than seventy financial institutions simultaneously, according to reporting by American Banker on a breach traced to Marquis Software's shared infrastructure. The patch existed. Many of the affected institutions almost certainly had recent penetration tests on file. Neither fact offered meaningful protection, because the vulnerability was present and exploitable in the window between assessments - which is to say, in the 345 days of operational reality that annual testing leaves unvalidated.
That arithmetic is not incidental. It is the structural problem underlying one of the most consequential exposure patterns in financial services security today.
The Gap Is a Design Feature, Not an Oversight
Annual external penetration testing, conducted over two to three weeks of active assessment, was a defensible model when banking infrastructure changed on predictable quarterly cycles. The regulatory frameworks that reference it - PCI DSS, the FFIEC IT Examination Handbook, NYDFS 23 NYCRR 500 - were written with that cadence in mind. None of them describe annual testing as sufficient. PCI DSS 4.0 Requirement 11.3.1 explicitly mandates external penetration testing after any significant infrastructure or application upgrade or modification. NYDFS's 2023 amendments strengthened continuous monitoring obligations alongside the annual testing requirement. The regulatory floor already assumes testing responds to change.
Modern banking infrastructure does not change on quarterly cycles. Cloud workload migrations, fintech API integrations, third-party portal launches, digital banking releases, and M&A integration work all generate new attack surface continuously. An annual test validates the infrastructure that existed when the engagement was scoped. Everything added after that date is unvalidated until the next engagement is scoped, contracted, and executed - a process that does not move quickly.
Threat actors do not wait. Mandiant's M-Trends 2026 report puts the 2025 median dwell time at fourteen days, a figure that reverses a multi-year declining trend. Espionage-motivated actors averaged 122 days inside compromised environments. CrowdStrike's 2026 Global Threat Report ranks financial services fourth among sectors targeted by interactive intrusions. The adversary model assumes continuous opportunity. The annual testing model assumed adversaries would respect the assessment calendar.
What Slips Through the Annual Model, Concretely
The Marquis breach illustrates one failure mode: a known vulnerability in widely deployed infrastructure that institutions had not patched because no active testing cycle had flagged it as a live risk in their specific environment. A different failure mode is structural to how annual engagements are scoped.
Consider a regional bank that operates a customer-facing mortgage origination portal through a third-party platform vendor, presented to applicants under the bank's own subdomain. The bank does not control the vendor's code, does not have access to its source code, and reasonably treats the vendor as responsible for its own application security. The hostname gets excluded from the annual penetration test scope. That exclusion is logical from a resource and responsibility standpoint. It is irrelevant to an attacker enumerating the bank's external perimeter, who will encounter the subdomain whether or not the bank's scope document listed it.
If the vendor's platform contains an exploitable vulnerability - an unauthenticated API endpoint, a permissive cross-origin policy, exposed tenant identifiers - the bank's external attack surface carries that risk under its own hostname. Any regulatory, fraud, or reputational consequence routes to the institution named in the URL. The vendor introduced the exposure; the bank absorbs the downstream impact. An annual assessment scoped against a six-month-old snapshot of infrastructure may never surface the asset at all.
This is not a hypothetical edge case. Vendor-operated portals fronted at institution-owned subdomains are common across retail banking, mortgage origination, and wealth management. The pattern of shared platform infrastructure creating cross-tenant exposure - where exploiting one institution's hostname surfaces data belonging to every other tenant on the platform - is a direct consequence of how modern fintech vendor relationships are structured, and it is not reliably detected by automated scanning alone.
Continuous Testing as an Operational Response
Closing the structural gap requires a testing program that responds to what infrastructure actually does, not to the schedule an engagement was contracted on. Three capabilities are central to that shift.
- Attack surface management that treats new assets as testing triggers. When a new hostname becomes reachable under an institution's domain - because a vendor was onboarded, a portal was launched, or an API was exposed - that event should initiate testing, not wait for the next annual scope conversation.
- Continuous external reconnaissance that does not honor internal scoping boundaries. If an asset is reachable on the open internet under a domain the institution owns, it is part of the institution's external attack surface regardless of which vendor operates it or what the last engagement's scope document said.
- Active human testing to establish exploitability, not just presence. Automated scanners identify exposed endpoints, missing authentication headers, and permissive CORS configurations. They do not chain those findings into realistic attack scenarios, validate cross-tenant data exposure, or determine what a downstream fraud or phishing operation would actually require. That work requires testers operating against production deployments.
The compliance question this model answers is also different from the one annual testing answers. The relevant question is no longer whether the institution tested last year. It is whether the institution tested the assets that actually changed, when they changed, against the infrastructure that actually exists today. Regulators who read PCI DSS 4.0, the FFIEC handbook, and the NYDFS 2023 amendments carefully already expect the answer to that second question to be yes.
The Marquis breach is, in one sense, a straightforward story about an unpatched vulnerability in shared infrastructure. In a more accurate sense, it is a story about seventy institutions whose testing programs were designed for a threat model that does not match the environment they actually operate in. Patching cadence is one part of the answer. Testing cadence - tied to infrastructure change, not to the calendar - is the other part that the annual model was never built to provide.
