TLDR
The Problem: Regional banks rely on third-party vendors for critical systems, but standard security questionnaires only measure what vendors claim to do, not what they actually implemented.
The Solution: Real third-party risk assessment requires technical validation: testing API security, reviewing authentication implementations, and examining how vendor systems connect to your core banking infrastructure.
The Reality: Most breaches happen because questionnaires said the vendor was secure while the technical reality told a different story.
Introduction
In August 2025, Marquis Software Solutions notified hundreds of community banks and credit unions that an “external actor” had accessed their data environment.[1]
The breach compromised personal and financial data affecting at least 70 financial institutions and an estimated 400,000 consumers.[2]
For the banks involved, their own internal systems were never touched. Their security controls functioned exactly as designed. Yet customer data was compromised anyway.
Every affected institution had almost certainly completed vendor risk assessments on Marquis. Security questionnaires were filled out, attestations provided, compliance certifications reviewed.
The paperwork indicated the vendor was secure. The technical reality told a different story.
This disconnect has become the defining pattern of third-party risk in banking. Vendor vulnerabilities were linked to 35.5% of all breaches in 2024, with 41.4% of these attacks involving ransomware.[3]
The problem is straightforward: security questionnaires measure what vendors claim to do, not what they actually implemented. A vendor can answer “yes” to “Do you implement multi-factor authentication?” while their API endpoints allow authentication bypass.
Third-party risk management in banking has evolved into a compliance exercise that creates the appearance of security without validating it.
What Questionnaires Actually Tell You
The Compliance Checkbox Problem
Security questionnaires measure policy existence, not implementation quality. A vendor can truthfully answer every question correctly while their production environment tells a completely different story.
Vendors have learned the “right answers” to standard security questions. Questionnaire fatigue leads to rushed responses, copy-pasted answers from previous questionnaires, or outright refusal to complete yet another assessment.[4]
The result is documentation that creates false confidence while missing the vulnerabilities that actually matter.
Three Critical Gaps
Multi-factor authentication: A questionnaire asks “Do you implement MFA?” The vendor answers yes.
What the questionnaire doesn’t reveal is whether their API endpoints enforce it, whether it can be bypassed through legacy authentication methods, or whether administrative accounts are exempted “for operational efficiency.”
Data encryption: The vendor confirms they encrypt data at rest.
The questionnaire doesn’t ask where encryption keys are stored, who has access to them, whether backups are encrypted with different keys, or if the same database that holds encrypted data also contains the decryption keys.
Penetration testing: The vendor reports they perform annual penetration testing.
Missing from the questionnaire: when the last test occurred, what scope was covered, what severity findings remain unpatched six months later, or whether the test included the specific systems that integrate with your bank.
Why Regional Banks Are Especially Vulnerable
Regional banks face particular exposure to this gap. Smaller institutions rely more heavily on third-party providers for core systems, have less internal security staff to validate vendor claims, and face regulatory pressure that incentivizes checkbox compliance over technical risk assessment.
Questionnaires can only offer a snapshot of a vendor’s cybersecurity posture while the actual risk continuously evolves.[5]
How Third-Party Vulnerabilities Actually Manifest
Understanding what questionnaires miss is only half the problem. The other half is understanding how these gaps actually manifest in real breaches.
Integration Points Create Attack Surface
Your core banking system connects to vendor platforms through APIs, and those integration points create attack surface that questionnaires never examine.
Breaches don’t happen at the policy layer documented in vendor responses. They happen at the technical integration layer where your systems actually communicate.
A single vulnerable third-party API can compromise the entire ecosystem, as one global bank discovered when attackers injected malicious code through a third-party API integration.[6]
Poorly designed APIs can leak customer information by returning more data than necessary, such as partial credit card numbers exposed through support channels.[7]
Broken object-level authorization allows attackers to access other users’ data by sending requests for data objects that should be protected with authorization controls.[8]
Implementation Gaps
A vendor confirms they implement multi-factor authentication, but in August 2025, attackers stole OAuth refresh tokens from Salesloft’s Drift integration with Salesforce, which allowed Drift to query Salesforce instances on behalf of over 700 customers.[9]
IBM API Connect, used by hundreds of companies in banking, healthcare, retail, and telecommunications, suffered a critical authentication bypass vulnerability that enabled unauthenticated threat actors to remotely access exposed applications by circumventing authentication.[10]
The Cascade Effect
When vendor environments contain embedded credentials, attackers who breach one vendor can exploit that access to reach further into another vendor’s environment. This is federated trust turning into federated risk.[9]
Each integration looks benign in isolation, but when chained together they create an attacker’s pathway across multiple organizations.
Your bank’s security is only as strong as your weakest vendor integration. One vulnerable vendor connection provides lateral movement into core systems.
Questionnaires don’t reveal these architectural vulnerabilities because they ask about policies, not about how APIs actually behave when attackers probe them.
What Technical Assessment Actually Looks Like
If questionnaires don’t reveal these vulnerabilities, what does? Technical assessment validates implementation, not just policy.
API Security Testing
API security testing forms the foundation of vendor technical assessment.
Manual penetration testing brings in security experts who attempt to exploit your APIs using the same techniques as real attackers, applying creative thinking to find attack vectors that automated tools miss.[11]
This means testing authentication bypass attempts on vendor API endpoints, verifying whether multi-factor authentication is truly enforced at the technical layer, and evaluating rate limiting, input validation, and error handling.
Testers attempt horizontal privilege escalation by trying to access another user’s data. They test vertical escalation by trying to elevate their privileges. Both attacks work by modifying IDs, roles, and tokens.[12]
Architecture Review
Architecture review examines how data actually flows between systems.
How does information move between your bank and the vendor? Where are authentication boundaries enforced? What access do vendor systems have to your infrastructure? How are credentials managed in the integration?
Architecture assessment analyzes how the API integrates with other system components, including databases, authentication, and third-party APIs.[13]
Access Control Validation
Access control validation tests whether documented policies match implementation.
Can support staff actually bypass logging or audit trails? Are role-based access controls enforced as documented, or do overly permissive configurations allow broader access than policy dictates?
Role-based access controls include restrictions around who has access to administrative features and the use of just-in-time access for accessing root functions.[14]
Incident Response Capabilities
Incident response capabilities matter when a vendor is compromised.
Can they detect a breach in their environment? How quickly would your bank be notified? What visibility do you have into their security monitoring?
Making It Practical for Regional Banks
Regional banks with limited security staff can’t technically assess every vendor. Prioritization is essential.
Critical vendors requiring deep technical validation:
- Core banking platforms
- Payment processing systems
- Customer-facing integrations
Lower-risk vendors can rely on questionnaires supplemented with periodic spot checks.
Include technical assessment requirements in vendor contracts. Periodic testing, not one-time review, provides ongoing validation that security controls continue to function as implemented.
Building Technical Assessment Capability
Regional banks with limited security staff face a practical challenge: technical assessment requires specialized expertise they may not have in-house.
Partner with Security Firms
Partner with firms that perform technical validation from an offensive security perspective.
Questions to ask potential assessment partners:
- What specific technical testing do you perform on vendor integrations?
- How do you validate API security and authentication implementation?
- Can you review our integration architecture for vulnerabilities?
- Do you provide actionable findings we can use in vendor negotiations?
Build It Into Your Process
Build technical assessment into vendor onboarding and renewal processes. Institutions can evaluate their third-party risk management programs as well as conduct third-party risk assessments using internal staff, a trusted partner, or choose a hybrid model.[15]
Don’t replace questionnaires. Supplement them with technical validation for critical vendors.
Community banks may outsource the monitoring of their third-party vendors to yet another vendor, however, such arrangements do not diminish a bank’s responsibility to operate in a safe and sound manner.[16]
Make It Sustainable
Make technical assessment sustainable through:
- Annual deep assessment for critical vendors
- Ongoing monitoring of vendor-related security events
- Technical review when vendors make infrastructure changes
- Including assessment rights in vendor contracts
The degree of oversight and review of outsourced activities will depend on the criticality of the products and services, access to customer information by the third-party vendor, and any specific risks attributed to the selected third-party vendor.[17]
Conclusion
Questionnaires document what vendors claim. Technical assessment validates what their systems actually do.
That gap caused 35.5% of breaches in 2024, including the Marquis incident affecting 70 financial institutions. In each case, the paperwork said vendors were secure while the technical reality showed otherwise.
Technical assessment addresses actual risk rather than documented compliance. Testing how vendor systems actually behave, examining how integrations function, and validating that security controls work as implemented addresses the disconnect between policy and reality.
Regional banks can build this capability through partnerships with firms that provide offensive security assessment, prioritizing critical vendors for deeper technical validation.
Security maturity means understanding that vendor risk assessment is a technical problem requiring technical validation. The question isn’t whether to move beyond questionnaires. It’s how quickly you can start validating what your vendors actually do, not just what they claim.
References
- ThreatLocker. “Ransomware cases highlight ongoing security pressure in financial services.” ThreatLocker Blog. Accessed January 2026. https://www.threatlocker.com/blog/ransomware-lawsuits-financial-services-vendor-breaches
- American Banker. “VPN vulnerability leads to data breaches at 70 banks.” December 4, 2025. https://www.americanbanker.com/news/vpn-vulnerability-leads-to-data-breaches-at-70-banks
- Venminder. “March 2025 Vendor Management News.” April 7, 2025. https://www.venminder.com/blog/march-2025-vendor-management-news
- Safe Security. “Vendor Security Questionnaire (VRAQ) Best Practices.” Accessed January 2026. https://safe.security/resources/blog/vendor-security-questionnaire-vraq-best-practices/
- BitSight. “Third-Party Risk & Vendor Assessment Questionnaire Template.” April 10, 2025. https://www.bitsight.com/blog/vendor-risk-management-questionnaire-template
- Rakuten SixthSense. “Securing Banking APIs: Challenges and Best Practices for Financial Institutions.” January 13, 2025. https://sixthsense.rakuten.com/blog/Securing-Banking-APIs-Challenges-and-Best-Practices-for-Financial-Institutions
- Payments Cards and Mobile. “Addressing API vulnerabilities: Plugging the holes in Open Banking.” March 24, 2025. https://www.paymentscardsandmobile.com/addressing-api-vulnerabilities-plugging-the-holes-in-open-banking/
- Kong Inc. “API Security Risks and How to Mitigate Them.” Accessed January 2026. https://konghq.com/blog/engineering/api-security-risks-and-how-to-mitigate-them
- Silverfort. “The Salesloft Drift breach: A cross-vendor attack.” September 26, 2025. https://www.silverfort.com/blog/the-salesloft-drift-breach-a-cross-vendor-lateral-movement-attack-that-requires-a-new-shared-security-model/
- BleepingComputer. “IBM warns of critical API Connect auth bypass vulnerability.” Accessed January 2026. https://www.bleepingcomputer.com/news/security/ibm-warns-of-critical-api-connect-auth-bypass-vulnerability/
- StackHawk. “API Security Testing Guide: How to Actually Secure Your APIs.” December 1, 2025. https://www.stackhawk.com/blog/api-security-testing-overview/
- AppSecure. “API Penetration Testing: A Complete Guide for Secure Integrations.” Accessed January 2026. https://www.appsecure.security/blog/api-penetration-testing-guide
- LuxeQuality. “API Penetration Testing: A Full Guide.” Accessed January 2026. https://luxequality.com/blog/api-penetration-testing/
- AuditBoard. “Mitigate Cyber Risks With a Vendor Security Assessment.” Accessed January 2026. https://auditboard.com/blog/mitigate-cyber-risks-with-a-vendor-security-assessment
- Baker Newman Noyes. “Interagency guidance released: managing vendors in banking.” December 17, 2024. https://www.bnncpa.com/resources/navigating-interagency-guidance-on-third-party-relationships-in-banking/
- Community Banking Connections. “Third-Party Cybersecurity Risk Management: Updates for a Changing Risk Environment.” Accessed January 2026. https://www.communitybankingconnections.org/Articles/2023/I2-I3/third-party-cybersecurity
- Community Banking Connections. “The Importance of Third-Party Vendor Risk Management Programs.” Accessed January 2026. https://www.communitybankingconnections.org/articles/2017/i1/third-party