A quarter of financial organizations don't assess fourth-party risk, according to Ncontracts' 2026 State of Third-Party Risk Management Survey. That's the blind spot a June 2026 breach at Klue, a third-party competitive intelligence platform, exposed: organizations can be affected by service providers they never directly onboarded or assessed.
Attackers entered Klue's systems through an old credential tied to a project the company had abandoned years earlier. Nobody had ever turned it off. That oversight exposed customer data at companies whose only connection to Klue ran through a vendor who did business with them — an example of fourth-party exposure most vendor risk programs aren't built to catch.
Here's what happened, what the incident reveals about third and fourth-party risk management, and what financial institutions (FI) should do if faced with a similar situation.
Related: Ransomware Risk Management: How to Defend Your FI Against Cyber Attacks
Attackers used a dormant credential to push unauthorized code into Klue’s integration service, harvesting OAuth tokens the company used to connect customer accounts to Salesforce. From there, the attackers pulled business contact information and account data out of connected Salesforce environments. Klue shut down the affected infrastructure and rotated the compromised credentials within a day of learning about the breach, but at least 11 companies have confirmed they were affected.
This incident resembles other recent breaches involving compromised OAuth connections, including incidents affecting Salesloft and Gainsight, and it’s becoming a repeatable way for attackers to reach dozens of organizations through one compromised vendor instead of breaching each one directly.
Related: When a Vendor Goes Dark: Lessons From the TruStage Incident
A strong response requires clear questions for the vendor, documented decisions, and an effective incident response plan, including a pre-assembled response team.
Here's what a strong response and a solid plan need to include.
Related: How to Create an Effective Incident Response Plan
Collect enough information from your vendor to understand the real extent of the breach, not just the headline version.
Decide in advance what constitutes a breach for your purposes and who owns the data under your contract. Not every compromised dataset warrants the same response.
Exposure involving regulated customer information should be prioritized immediately and assessed against contractual, legal, and regulatory notification requirements. This includes non-public personal information under the Gramm-Leach-Bliley Act, along with anything else your primary regulator requires you to report on a set timeline.
Everything else, like business contact information, should also be addressed, as it fuels targeted phishing campaigns that extortion groups run against affected companies. It doesn't call for the same escalation as exposed account numbers or Social Security numbers.
Send a letter or email to the vendor requesting a root cause analysis, addressed to whoever your contract names for official correspondence. This isn't the moment for threats about contract violations. It's an information-gathering exercise, and a documented one that shows regulators you pursued answers even if the vendor is slow to respond. Keep a log of all communication.
A well-rounded incident response team pulls in risk, compliance, legal, and communications alongside IT. It’s helpful to designate one person as the incident response manager. This person doesn't necessarily need technical expertise. It's more important that they are organized and comfortable coordinating across departments. Assign a single point of contact for vendor communication, and plan your external messaging, including a capable spokesperson.
Related: Incident Response Plan Checklist
Documentation separates a well-handled incident from a regulatory problem. Banks have a 36-hour notification window to report an incident to their primary federal regulator once, and credit unions have 72 hours under NCUA's rule. Several states have their own deadlines.
Don't wait for your vendor to finish its investigation before assessing your notification obligations. Document your reasoning and loop in compliance and counsel early.
Run a post-mortem a quarter after the breach to evaluate how the vendor's response held up and what your own process should require differently next time. When the relationship comes up for renewal, use it as leverage. Negotiate stronger recovery terms into the contract, and ask the vendor to share its recovery time and recovery point objectives so you can verify they hold up under testing, not just on paper.
Shop around for comparable vendors at renewal time, even if you have no plans to switch. One core question to consider for all your vendor relationships: What happens to us if they fail? That answer should drive how much backup planning the relationship needs.
Related: Business Continuity Planning (BCP) Q&A for Financial Institutions
Klue is one incident, but the exposure it created wasn't limited to the company’s customers. That's the reality of fourth-party risk: the breach that affects your organization might come from a source you never expected.
A strong response starts with the right questions and clear documentation. A strong defense starts earlier than that, with a vendor inventory that identifies who your vendors are connected to, not just what they do themselves.
Curious where your own fourth-party risk exposure sits? Our fourth-party risk checklist helps you assess visibility, contract coverage, concentration risk, and examiner defensibility across your vendor ecosystem.