TruStage, a third-party financial services provider, shut down its network after a cybersecurity incident, and credit unions across the industry are now working through what that means for their members.
Here's what's known so far and what it means for credit unions caught in the middle. Take this moment to better understand how your financial institution (FI) can strengthen its own business resiliency and incident response plans if a critical vendor ever goes dark.
Related: Business Continuity Planning and Disaster Recovery: The Differences
TruStage is a Wisconsin-based provider of insurance and financial services to credit unions and their members. The company took its network offline this week after detecting a cybersecurity incident, shutting systems down as a precaution while external specialists work to investigate and contain it. TruStage's site confirms the outage and says it's “activating business resiliency plans” while working toward a resolution.
Credit unions use TruStage to handle add-on products like GAP insurance, mechanical repair coverage, and payment protection for members as well as services related to retirement and investment accounts. As of July 20, the vendor hasn’t confirmed when the incident began, how its systems were affected, or whether non-public personal information (NPI) was accessed.
Related: How Is Your Financial Institution Managing AI Cybersecurity Risks?
A third-party outage rarely stays contained and can multiply the risks across the organization.
More than half of FIs — 52%, per Ncontracts' 2026 State of Third-Party Risk Management Survey, up from 46% the year before — reported a third-party cyber incident in the past year. When a vendor serves a large share of an industry while holding sensitive data across many institutions, an incident isn't just one FI’s problem. It's a sector-wide exposure.
Related: Top Insights from the 2026 TPRM Survey
A vendor outage puts one job first: protecting members and customers from harm, while your FI keeps a clean, defensible record of everything that happens.
From there, start a manual intake process. Document your member and customer requests, give them a reference number, and hold everything for batch submission once the vendor is back online.
Regardless of product, the same principle applies: if a claim depends on confirmation that hasn't happened yet, don't close it out or waive anything tied to it. If an outcome could penalize a member for the delay, like a late fee or a paused benefit, pause until the vendor is back online.
On the regulatory side, don't wait for the vendor to finish its investigation before assessing reportability. Document that reasoning either way, and loop in compliance and counsel early.
Once the vendor confirms restoration, the work shifts to reconciliation:
Related: How to Create an Effective Incident Response Plan
The best time to think about vendor outage response is before you need it, and contract management is where that starts. Notification timelines matter most. A contract that only promises notice "as soon as reasonably practicable" gives an FI far less to work with than one that specifies a number of hours. Carefully negotiate expectations for downtime and breach liability, and ensure the vendor is contractually required to keep you updated during an incident, so you're not piecing things together from the news instead.
A few habits build on that foundation, and they hold regardless of what any single vendor's investigation eventually finds:
Related: How to Organize ERM Documentation: A Guide for FIs
Analyze every incident for lessons learned while the details are still fresh. Assess what worked in your response, what didn't, and what your vendor contracts should require next time.
A vendor's bad day is out of your control. What happens next isn't.
If a scenario like this isn't part of your tabletop testing yet, our BCP Tabletop Exercise Template gives you a starting point to build one.