WHAT 345 DAYS OF UNTESTED EXPOSURE LOOKS LIKE AT A BANK
Sponsored by SPROCKET SECURITY
In April, a single VPN vulnerability opened the door to data breaches at more than seventy financial institutions running Marquis Software’s infrastructure, according to reporting from American Banker. A patch existed, and most affected institutions had recent penetration tests on file, yet the exposure still spread across portfolios. The lesson is not about a single flaw, but about what happens when testing happens on a limited cadence in a shifting digital banking landscape.
The exposure gap is real, and it is systematic. The math is simple: a standard external penetration test runs two to three weeks of active testing each year. That leaves roughly 345 days of operational reality unvalidated. Industry observers have noted that dwell times, even in the best cases, stretch beyond a single annual exercise. The M-Trends 2026 report shows a 2025 median dwell time around fourteen days, with espionage actors averaging 122 days in some scenarios. At the same time, the 2026 Global Threat Report from CrowdStrike places financial services as a prominent target for interactive intrusions. The implication is clear: attackers do not wait for the next annual assessment, and neither should defenses.
REGULATORS SET THE FLOOR AGAINST A SLOW THREAT MODEL
Regulatory expectations are clear, but they are framed as floors, not ceilings. PCI DSS, FFIEC, and NYDFS reference penetration testing within their guidance, yet none prescribe a rigid annual cadence as sufficient for modern infrastructure.
- PCI DSS 4.0, Requirement 11.3.1, mandates external penetration testing after any significant upgrade or modification to infrastructure or applications.
- The FFIEC IT Examination Handbook presents penetration testing as part of ongoing vulnerability management rather than as a single, discrete annual event.
- NYDFS 500.05 requires annual testing alongside continuous monitoring obligations amended in 2023 (23 NYCRR 500).
These frameworks assume testing follows change. The reality today is that digital banking platforms are continuously evolving through cloud migrations, API integrations, third-party portal launches, and M&A activity. Such changes create new surfaces between annual tests, surfaces that regulators already expect to be covered through continuous assessment.
ANNUAL PENTESTS LEAVE 345 DAYS UNVALIDATED. HERE'S THE FIX.
The issue is not that testing happens too little, but that the cadence does not align with how banks actually operate. Technology moves fast: cloud workloads shift, fintech partnerships appear, and vendor-managed portals integrate into the enterprise. To bridge the gap, tests must follow the changes, not wait for the next calendar year.
- A continuous testing approach treats new hosts and exposed services as triggers for testing, rather than waiting for a quarterly or annual scope update.
- Vendor-operated surfaces, especially portals on the bank’s own subdomain, often fall into a gray area in scoping conversations. They can exist outside the bank’s direct control yet remain part of the external attack surface.
- Relying solely on automated scanners may misinterpret the risk: scanners can flag surface exposure but cannot always reveal the downstream impact or cross-tenant data exposure that longer-term, human-driven testing can uncover.
WHAT THE GAP PRODUCES, DOCUMENTED
A recent engagement at a regional bank exposed a concrete example of how the gap manifests in real life. A customer-facing mortgage origination portal, hosted on a subdomain controlled by a platform vendor, carried the bank’s branding but was operated by a third party. The risk surface lay in an API endpoint that returned organization records when given a tenant ID. The endpoint required no authentication and accepted requests from any browser, enabled by a permissive cross-origin policy.
Crucially, the tenant ID was visible in the portal’s public-facing files, rendering it unnecessary to guess the value. By incrementing the tenant ID, an attacker could retrieve records for the next institution on the shared platform, exposing data for every bank on the vendor’s ecosystem, plus the vendor’s own internal tenants. The returned data included named staff, business email addresses, direct-dial phone numbers, job titles, and an internal code used to map borrower submissions to specific personnel.
That internal code was more than a curiosity: it could be used to submit a loan application in the name of a named officer, and the system would treat the submission as legitimate intake within the loan origination workflow. The bank did not create this exposure; the platform vendor did. The bank’s annual external assessment may have covered the hostname at the time of testing, but it did not surface the full scope of the vulnerability. Automated scanners might have flagged the open endpoint, the permissive CORS policy, or missing authentication, but they would not have walked through tenant IDs, validated cross-tenant data returns, or connected the staff-attribution code to a submission forgery scenario. The downstream risk—data belonging to every institution on the shared platform and its link to legitimate banking processes—was real and regulatory in nature because it could enable fraud, phishing, or noncompliant activity tied to the wrong institution.
CONTINUOUS TESTING IS THE OPERATIONAL ANSWER TO THE ENGAGEMENT ABOVE
Why did the annual model miss this kind of finding? There are three direct reasons:
- The asset entered the external footprint when the vendor onboarded the platform, not when the bank’s pentest was scoped. If the scope snapshot was six months old, the hostname might not even appear in the test plan.
- The asset fell into a gray area for annual scope: vendor-hosted portals fronted on the bank’s own domain. The bank neither writes the code nor owns the release cycle, which makes it easy to exclude from the traditional annual assessment.
- The exposure required active, human testing to reveal the true risk. A scanner could detect openness and cross-origin permissiveness but would not deliberately enumerate tenant IDs, verify cross-tenant data boundaries, or tie the risk to a real-world fraud scenario.
Sprocket Security operates on a continuous testing model built around these insights. The attestation that follows describes the state of the infrastructure that existed when testing occurred, not a snapshot from months past. Automation can surface surface-level exposure, but human testers are needed to understand what is actually exploitable and to anticipate downstream impact. Continuous external reconnaissance recognizes that new hosts and services should trigger testing, and it maintains visibility over a production footprint that evolves week to week.
THE GAP IS STRUCTURAL, NOT A CADENCE PROBLEM
The 345-day figure is not a marketing number. It reflects a structural characteristic of the traditional annual testing approach. Regulators described a process that assumed changes occurred on quarterly release cycles and were tested accordingly. In practice, many institutions test what existed at the time of the engagement, according to the scope that existed, and treat the resulting attestation as a description of current exposure. That description inevitably becomes less accurate with every passing day after the test.
The institutions that close the gap are not the ones that simply test more often. They are the ones whose testing program adapts to what their infrastructure actually does, focusing on the changes and the surfaces those changes reveal.
SEE HOW YOU CAN BUILD YOUR CASE FOR CONTINUOUS TESTING IN THE FINANCIAL SPACE
Today’s landscape demands a more dynamic approach to security testing. Continuous testing aligns with how institutions operate, where changes are constant and exposure can emerge any day. It is about validating the actual attack surface as it evolves, not just the surface that existed when the last report was written.
Sponsored and written by SPROCKET SECURITY
Bank | Continuous Penetration Testing | Continuous Testing | Cybersecurity | Sprocket Security
Previous ArticleComments have been disabled for this article.
