TruStage Rebuilt Rather Than Restored Because the Attackers Reached the Backups
TruStage identified a cybersecurity attack on July 11, 2026. Its recovery page, updated September 18, still lists claims submission, claims processing, claims payout, policy servicing, retirement distributions, and annuity withdrawals as partially available, and says some services remain unavailable.
The recovery timeline is the visible story. The more useful detail sits underneath it.
In its July 31 update, TruStage wrote that because this was a particularly broad attack on its network and systems, it rebuilt parts of its infrastructure so systems could be brought back safely rather than simply turned back on. President and CEO Terrance Williams has since described the attack as damaging major portions of the operating environment and compromising many of the backups the company would ordinarily have relied on. The company chose to rebuild in the cloud.
Read that sequence again if you run a recovery program. The backups were in scope.
Rebuild and restore are not the same operation
Most recovery plans assume a clean copy exists somewhere and that the work is bringing it back. Restore is a known quantity. You have tested it, you have a rough time estimate, and you can tell your board what it looks like.
Rebuild is a different exercise. You are standing up infrastructure, validating that no malicious code or persistence traveled with it, and bringing applications back in sequence. TruStage described refreshing laptops and updating security measures for its teams as a necessary step before staff could re-engage with systems.
The public timeline shows what that costs. The attack was identified July 11. TruStage targeted mid-August for the majority of key processes. It cancelled its Discovery 2026 conference on August 20. By early September the claims center was operating again with some transactions still manual. In late August, contact centers for retirement, consumer insurance, annuity, and pension risk transfer handled more than 42,000 calls in roughly a week. Ten weeks after detection, the recovery page still shows partial availability across core service lines.
None of that is a criticism of the response. The point is the order of magnitude. If your recovery time objective assumes restore and your incident turns into rebuild, the gap between plan and reality is measured in months.
The recovery assumption worth testing this quarter is not whether your backups exist. It is whether an attacker with access to your production environment could reach them. If the answer is yes or unknown, your documented recovery time objective describes a scenario you may not get. Immutability, credential separation, and a restore path that does not depend on production identity are what turn a backup into a recovery capability.
What this means for a credit union that is not TruStage
TruStage serves credit unions rather than being one, which puts most readers of this on the downstream side.
Three things follow.
The data question is still open, and that is normal for an investigation of this size. TruStage engaged Mandiant and has said that if it determines member personal information is involved, it will notify affected partners first and work with them on notification and reporting. For a federally insured credit union, notification from a third party regarding a reportable cyber incident is one of the triggers under 12 CFR 748.1(c), specifically the third-party prong at (c)(1)(i)(C), and the 72-hour clock runs from that notification or from your own reasonable belief, whichever is sooner. If that call comes, the clock starts then, not when your investigation finishes.
Operational disruption at a vendor produces member harm that your members attribute to you. Reporting through the recovery period described missed insurance payments, inaccessible retirement funds, delayed disability benefits, and difficulty collecting on life policies. Whatever the contractual allocation says, the member conversation happens at your branch.
Vendor concentration compounds. TruStage products sit across lending protection, consumer insurance, annuities, retirement, and wealth management at hundreds of credit unions. A single provider outage reaches multiple product lines at once, which is a different risk profile than several vendors each carrying one line.
That concentration is worth quantifying before you need the number. Most vendor risk assessment processes rate providers individually, which produces a tidy list and hides the case where one name appears against six different member commitments. The exercise that surfaces it is inverting the list: start from what you promise members, then note which vendor stands behind each promise. Names that repeat are your concentration, whatever their individual risk rating says.
What to do now
Ask your critical vendors one question in writing: are your backups reachable from your production environment. Not whether they have backups. Whether an attacker who compromises production can reach the recovery copy. This belongs in your vendor due diligence assessment and it is a question most questionnaires do not ask.
Separate your recovery time objective into a restore number and a rebuild number. If you only have one figure, it is almost certainly the restore case. Knowing both changes what you tell your board and what you plan for.
Test a restore that does not use production credentials. If your recovery path authenticates through the same identity provider an attacker would already hold, that path may not be available when you need it. This is testable in an afternoon and rarely tested.
Write down which member-facing commitments depend on each critical vendor. Not systems. Commitments. Claims paid, benefits disbursed, protection honored. That list is what you will be asked about, and building it during an outage is worse than building it now.
Check whether your incident response plan has a vendor notification path. When a provider tells you an incident occurred but cannot yet say whether your data was involved, someone at your institution needs to own the reasonable-belief determination. Name that person before you need them.
Source note
This article is based on TruStage's recovery and restoration progress update published July 31, 2026 in its newsroom, and on its public outage resource hub and recovery status page as updated September 18, 2026; statements by President and CEO Terrance Williams as reported by CUToday.info and Credit Union Daily; NCUA's cyber incident notification rule at 12 CFR 748.1(c); and reporting by CUToday.info, Credit Union Times, and CrossState Credit Union Association. Recovery status and the forensic data determination were both unresolved as of the most recent public updates.
This incident is active. Verify the current state of TruStage's disclosures before relying on any detail here.
Disclaimer
This article is provided for general information and does not constitute legal advice. Regulatory requirements, compliance dates, examiner priorities, and enforcement posture change frequently. Verify current requirements against primary agency sources and your legal counsel before acting on anything described here.