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
What Happened in the Klue Breach?
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
What to Do When a Third- or Fourth-Party Breach Reaches You
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
Ask the Vendor Questions
Collect enough information from your vendor to understand the real extent of the breach, not just the headline version.
- When did it occur, and when did the vendor learn about it? That gap matters for your own notification timeline, since many state laws carry tight breach notification deadlines.
- What was taken, and where did it happen? Push past a vague "customer data was affected" and get specifics on data types, volume, and root cause.
- Does this vendor rely on third-party integrations, and would it know if one of those tools were compromised instead of the vendor itself? If it can't answer, that's worth documenting as its own finding, and a sign your vendor inventory may have the same blind spot.
- What containment steps has the vendor taken? Ask whether credentials have been revoked and rotated, and whether the exposure is fully contained.
Define What Counts as a Breach Before You Need To
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.
Document Everything in Writing
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.
Assemble the Incident Response Team
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
Prepare for Exam Scrutiny and Meet Notification Deadlines
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.
Follow Up and Line Up Back-Up Vendors
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
Building Fourth-Party Risk Into Your Vendor Program
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.
