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
What Happened to TruStage?
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?
What Are the Risks of a Third-Party Incident?
A third-party outage rarely stays contained and can multiply the risks across the organization.
- Financial risk: When add-on products like GAP insurance or mechanical repair coverage go down with a vendor, FIs lose the revenue from sales that would've closed through that channel.
- Compliance risk: An incident can trigger notification obligations on more than one front regardless of whether the vendor has finished its investigation. Under the NCUA's 72-hour rule, for instance, a credit union must assess reportability based on what it knows, not what the vendor eventually discloses. Regulators don't distinguish between an institution's failure and a vendor's failure.
- Operational risk: Staff lose system access, members can't complete routine transactions, and the FI runs on manual workarounds until service is restored — shaping how members experience the institution for as long as the outage lasts.
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
How Should My FI Respond to a Third-Party Vendor Outage?
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.
- Log everything, lose nothing. Every claim, enrollment, cancellation, or change request gets captured with a date and time stamp, even if it can't be processed yet.
- Preserve the effective date. The date a member contacts you should be noted as the official date of their request, even if it can't be entered into the vendor's system until service is restored. This protects members from being harmed by downtime that isn't their fault.
- Toll time-sensitive deadlines. If a claim, enrollment, or cancellation window could lapse during the outage, extend it and document the extension.
- Route through a single point of contact. One designated owner handles all vendor communication, so nothing falls through the cracks or gets duplicated.
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:
- Submit logged claims and enrollments in batch, preserving original dates.
- Reconcile the manual log against the vendor's confirmations to make sure nothing was dropped or duplicated.
- Lift any temporary holds and correct member records as needed.
- Close the incident, capture what was learned, and update the vendor's continuity plan.
Related: How to Create an Effective Incident Response Plan
How Can FIs Prepare for a Third-Party Vendor Outage?
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:
- Document as you go, not after the fact. Real-time notes on what happened, who was told what, and when, hold up far better under regulatory or legal scrutiny than a reconstruction built from memory weeks later.
- Build a dedicated incident response team. A group that already knows its roles moves faster than one figuring out who's in charge while a vendor's still down.
- Run tabletop exercises that test this scenario. A 'critical vendor goes dark with no explanation' exercise surfaces gaps that a general disaster-recovery test won't. Extend at least one exercise into a functional test with a key service provider, like a PR firm or cyber insurance carrier, so you know how that piece moves under pressure, too.
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.
