A credit union’s promises in an outage are set by its architecture, years before the attack

The week

At the end of June 2024, members of Patelco Credit Union, a large California credit union based in Dublin, could open their banking app on a Saturday morning to check that rent had cleared and find nothing there.

Patelco was not a small institution. Founded in the 1930s to serve employees of Pacific Telephone, it had grown into one of the larger credit unions in the country. Press reports put its assets at more than $9 billion. Its members were spread across California and beyond, and many of them used digital banking as their main way to manage money.

On June 29, 2024, Patelco detected a ransomware attack. Ransomware is malicious software that criminals slip into an organization’s network to lock up its computer systems, and often to copy its data, so they can demand payment to undo the damage.

Patelco’s first move was to shut down several of its own banking systems to contain the attack. That sounds drastic, but it is standard practice: when a fire is spreading, you close the fire doors, even if it means people cannot walk through them for a while. The cost was immediate. Online and mobile banking went dark. Many electronic transfers stopped. Parts of the contact center, the phone and service operation members call for help, went down too.

The credit union’s own updates traced the outage day by day. On June 30 it told members that online banking, the mobile app and the call center were down, along with electronic transfers including Zelle, direct deposit, balance inquiries and payments. Cards worked in a limited way, and members were pointed to shared branch and ATM locations, the cooperative networks that let one credit union’s members use another’s branches and machines.

On July 2 Patelco said direct deposits would be credited and processed before withdrawals, so that incoming pay would be there to cover outgoing items. On July 3 it said its core systems had been validated and that members’ money was safe. On July 5 it listed what was working in limited form: Patelco checks, cards with limits, direct deposits, check and cash deposits, previously scheduled bill payments and incoming ACH transfers.

Through the week of July 8, digital banking stayed offline. The credit union posted regular public updates to keep members informed. According to those updates and local news reports, not everything stopped. Debit and credit cards, ATMs and branches kept working, though with limits. A member could still buy groceries or take out cash, but could not log in to see a balance or move money online.

The credit union was rebuilding as it went. On July 7 it said the network had been stabilized and transaction processing had begun, without giving a date for full service. On July 9 it said it expected to work through the backlog of queued transactions by the end of that week. Members were told that loan holders would not be penalized for missed payments during the outage.

Patelco was not the only financial name in the news. Evolve Bank & Trust, a bank that served many fintech companies, had confirmed a cybersecurity incident in late June after the LockBit group claimed it. CDK Global, which runs software for car dealerships, had been hit by a ransomware attack in mid-June that disrupted thousands of dealers for weeks. Patelco’s case stood out because its customers were ordinary households cut off from their own accounts.

Patelco also made commitments about money. It said it would waive overdraft, late and ATM fees, and it said it would reimburse outage-related late fees that members were charged by other companies, such as a utility or a card issuer, because a payment could not go out on time.

Online banking and the mobile app came back on Monday, July 15, after more than two weeks offline. Some services, such as opening new accounts, loans and electronic statements, took longer to return.

The announcement of that date came on Saturday, July 13, in an update signed by the chief executive, Erin Mendez. It said members would be able to view balances and move money from Monday, though electronic statements would not yet be available. It also said most Patelco fees would be waived automatically for July and August, and that late fees charged by other companies could be reimbursed with documentation.

One big question hung over that week: had the attackers stolen member data, or only locked systems? That was not yet publicly settled. The answer would arrive on a very different timetable from the restoration of service, and that gap matters as much as anything else in the story.

For about two weeks after June 29, 2024, Patelco’s members experienced a ransomware attack not as a technical event but as a list of things they could not do. They could not check a balance on their phone. They could not send money to a friend. Some could not reach anyone on the phone. The striking point, looking back, is that most of that list was written long before the attack began.

Members brought four questions, in roughly this order: can I use my money, what happened to my data, how do I get back in safely, and who pays for the harm. The answer to each depended mostly on design and policy decisions that an institution makes in calm conditions, often years earlier, in meetings about contracts, budgets and system upgrades. The response team working through the nights after the attack could change those answers only at the margin.

The argument applies to anyone who leads a bank, a credit union, a hospital or a public agency. Your customers’ experience of your worst week is being designed right now, whether or not anyone in the room sees it that way.

The form the argument takes differs by type of institution. A credit union is a member-owned cooperative, and many credit unions buy core processing, digital banking and card services from the same small set of vendors and credit union service organizations. The NCUA, unlike the federal banking agencies, has no authority to examine those vendors directly, and has asked Congress for that power for years. A credit union’s resilience is therefore set largely in its contracts.

A community bank faces similar vendor concentration but answers to the FDIC, the OCC or the Federal Reserve. Since 2022 those agencies have required banks to notify them within 36 hours of a significant computer-security incident, and their service providers must alert the bank. A large bank usually runs more of its own technology, which gives it more control over segmentation and recovery and more surface to defend. Health systems and public agencies face the same structure with different regulators: their patients and residents also experience an attack as a list of things they cannot do.

Five pieces of machinery behind the outage

A few pieces of technology come up again and again in what follows.

Ransomware. As described above, ransomware is software that criminals use to scramble an organization’s files and systems so they cannot be used, and often to copy data out first so they can threaten to publish it. Attackers typically get in unnoticed, move around the network for days or weeks, and only then trigger the lock-up. That is why, in Patelco’s case, the date the attack was detected and the date the intruders first got in turned out to be different, as we will see.

The core banking system. Every bank and credit union runs on a “core”: the central system of record that knows every account, every balance and every transaction. Tellers, apps, statements and loan systems all read from and write to the core.

Cores come in two broad models. Some institutions run the core software in their own data center or private cloud. Others use a service bureau, where the vendor runs the core for many institutions and each connects to it. The model shapes an attack. A service bureau core may be untouched when the institution’s own network is compromised, but the connections to it must be cut until the institution is trusted again. An in-house core lies inside the blast radius and must be validated before it is reconnected.

Containment. When an attack is found, the security team’s first job is to stop it spreading. That usually means disconnecting or shutting down systems, including ones that might be perfectly healthy, because no one yet knows how far the intruder reached. Containment protects the institution, but every door that closes is a service that members lose.

Card networks and processors. When you tap a debit card at a pharmacy, the request does not go straight to your credit union. It travels through a card network and a card processor, outside companies that route and approve transactions. Those outside companies can often approve purchases on the credit union’s behalf when the credit union itself is unreachable. This is called “stand-in processing,” and it works within preset limits, such as a maximum amount per purchase or per day.

Credit unions have a second cooperative layer. Shared branching networks let a member of one credit union make deposits and withdrawals at the branches of many others, and surcharge-free ATM networks extend that to cash machines. Patelco pointed members to both in its first updates. Those networks work only as far as the member’s balance and identity can be confirmed, so their usefulness in an outage depends on what information the processor and network still hold.

Network segmentation. This means dividing an organization’s computer network into separate compartments, so that trouble in one need not reach the others. A well-segmented network lets a team isolate the infected areas while keeping other services running.

How the five interact, and the sixth piece nobody sees

The pieces combine in a predictable order. The attacker’s reach determines what containment must switch off. Segmentation determines how much of that is collateral. The core’s model determines how long validation takes. The card processor’s stand-in rules determine what members can still buy in the meantime.

The piece that decides how long the outage lasts is usually the backup. If clean copies of the core data and system images exist offline, or in storage the attacker cannot alter, recovery is a rebuild. If backups were reachable from the compromised network and were encrypted or deleted, recovery becomes reconstruction. Ransomware groups routinely look for backups first for exactly that reason.

The financial industry built a shared answer to the worst version of this problem. Sheltered Harbor, an industry initiative begun in the mid-2010s, sets a standard for keeping protected, immutable copies of account data. The copies sit in a vault that cannot be reached from the institution’s production systems. The aim is that customer balances can be restored, if necessary through another institution, even if an attacker destroys the primary systems. Participation is voluntary, and many smaller institutions rely on their core vendor’s backup arrangements, which they should test and not assume.

Using the money: what the wiring decides

Members do not care which server is down. They care whether a paycheck lands, whether rent goes out and whether the card works at the pharmacy. Those outcomes follow the wiring.

Card authorizations and ATM withdrawals usually route through card processors and shared networks. As explained above, those can approve transactions on the issuer’s behalf within preset limits when the issuer is unreachable. Branch tellers work against the core. Online banking, bill pay and person-to-person transfers tend to sit closest to the systems a containment team switches off first, because they are connected to the internet and are therefore the most exposed.

That pattern matches what Patelco’s updates described: cards and branches worked in limited form while digital channels were dark. A member could still buy fuel. A member could still walk into a branch. But the services that many younger members used every day, the app and online transfers, were gone.

Luck had little to do with it. The pattern reflects choices about processor contracts, stand-in limits and network segmentation. An institution can make those choices on purpose.

Payments that do not travel on cards

Cards were the visible part of Patelco’s story, but much of a household’s money moves through ACH, the batch network that carries payroll, benefits and bill payments. ACH files arrive whether or not the receiving institution is ready. During an outage, incoming items queue up, and the institution must decide in what order to post them once it can.

Patelco’s July 2 decision to credit direct deposits before processing withdrawals was a posting-order choice. Posting credits first means a member’s pay covers the rent debit that arrives the same day, instead of the rent bouncing and the pay landing afterwards. Posting order has been a source of fee disputes for years, so an institution should decide its outage rule in advance and write it down.

Backlogs carry their own risks. When a large queue of transactions posts in a short period, members see duplicates, out-of-order entries and temporary negative balances. Patelco’s later guidance acknowledged duplicate-looking entries for returned items. Operations teams need rules for when to return an item, when to hold it and when to pay it. They should also prepare a member-facing explanation before the backlog posts, not after the calls start.

Some members routed around the outage. Patelco noted that Venmo and PayPal remained usable, because those services held balances outside the credit union. That reflects how households now spread money across institutions and apps. It also means an outage can permanently move some activity away from the institution, which is a cost that rarely appears in an incident budget.

Validating the core before reconnecting it

Patelco said on July 3 that its core systems had been validated. Validation means confirming that balances and transactions are complete and unaltered, and that the systems hold no attacker tools, before anything is reconnected. It typically involves reconciling balances against the last trusted records, scanning rebuilt systems and resetting every privileged credential.

That step explains why restoration took two weeks even after the core was confirmed sound. Each channel that reconnects to the core, from online banking to bill pay, must be rebuilt or cleared in the same way. Each one is a path an attacker could use to return. An institution that wants faster restoration needs to know, in advance, which channels can be rebuilt from clean templates and which require weeks of manual work.

How to make those choices deliberately

The starting point is a dependency map. This is a document, often a large diagram or spreadsheet, that ties each member function to the systems behind it. “Receive direct deposit” connects to certain systems. “Pay a bill online” connects to others. Then, for each line, the team asks a blunt question: if we isolate this system for two weeks, what stops?

Tabletop exercises should run against that map, not against a generic ransomware scenario. A tabletop exercise is a rehearsal around a conference table: leaders walk through a realistic crisis step by step and talk about what they would do. The value comes from specifics. “Ransomware hits us” is too vague to teach anything. “We have shut down the online banking servers and the bill-pay platform for ten days; it is the first of the month” forces real decisions.

The map usually exposes a few cheap improvements:

• Stand-in limits can be set by member segment so that most members can still buy groceries and fuel.
• A status page, the public web page where updates are posted, can be hosted entirely outside the core environment, so it stays up even when everything else is off.
• Branches can have a written manual procedure for urgent payments, such as rent or payroll for small business members.

There are trade-offs, and a leader should hear them plainly. Higher stand-in limits mean more overdrafts to reconcile later, because the card processor is approving purchases without seeing the real balance. Every channel kept independent is another integration to secure, and it is useless if it shares administrator credentials, the master passwords that let staff manage systems, with the network the attacker is in.

A rehearsal that finds three problems

Take a regional credit union with 200,000 members. Its dependency map shows that the mobile app, bill pay and transfers between members all run through one online banking platform that sits next to the core. Cards run through an outside processor. In a tabletop exercise, the team “switches off” online banking for two weeks and discovers three problems: the processor’s stand-in limit is set very low for everyone, the status page is hosted on the same servers as online banking, and branch staff have no written process for a member who needs to pay rent today. None of those fixes requires a major technology project. Each requires someone to decide, in advance, what the member experience should be.

The data: a slower clock

Availability and data exposure move on different clocks. Availability is whether services work. Data exposure is whether personal information, such as names, account numbers or Social Security numbers, was copied by the attacker. Restoring service is an engineering job. Establishing what was stolen is a forensic investigation, a detailed reconstruction of what the attacker did, and it takes longer.

In early July, Patelco’s public updates were about services. The data answer came later. The credit union’s August notice to individuals said an unauthorized party had first gained access on May 23, 2024, more than a month before the attack was detected. Its initial filing with the Maine attorney general counted about 726,000 affected people. An amended filing raised that to about 1.01 million.

Forensic scope tends to widen like this, because investigators work outward from what they find first. They locate one compromised system, then follow the trail to the next, and the next. Early numbers are almost always floors, not ceilings.

What the attackers took, and why the second extortion matters

When notices went out, they listed the data involved. According to the notice reported by BleepingComputer, it varied by person and included names, Social Security numbers, driver’s license numbers, dates of birth and email addresses. That combination is enough for identity theft, which shaped both the protection offered and the legal exposure.

Modern ransomware is a double extortion business. The group encrypts systems to stop the institution operating, and copies data to threaten publication. Restoring service answers the first threat. It does nothing about the second. An institution that recovers from backups without paying may still face the publication of member data, which is what happened at Patelco in mid-August.

Whether to pay is a separate decision, made with law enforcement, counsel and insurers. The Treasury Department’s Office of Foreign Assets Control has warned that paying a ransom to a sanctioned person or group can violate sanctions law. Payment also offers no reliable guarantee that stolen data will be deleted. Those are reasons many institutions decide not to pay, and they mean the data track must be planned on the assumption that publication may happen.

How to talk about data before you know the answer

Members still need to hear something about their data in week one. Silence breeds rumor. The safest approach is two separate tracks:

• Service updates go out daily at a fixed time, even when little has changed. Predictability itself is reassuring.
• Data updates go out only when the investigation reaches a milestone, and they say clearly what is known and what is not.

Early reassurance that there is no evidence of data theft is the statement most likely to be contradicted. It is technically true at the moment it is spoken, because the investigators have not yet found the evidence, but members hear it as “your data is safe.” It should be avoided unless forensics are complete.

A middle path is available. An institution can say that the investigation is under way and that outside forensic experts are involved. It can promise to notify affected people directly if their information is involved, and say when the next data update will come. That statement stays true however the investigation turns out. It also gives members a concrete step they can take now, such as placing a fraud alert or watching for suspicious messages.

The regulatory clocks

The regulatory clocks are separate again. Since September 1, 2023, federally insured credit unions must notify the NCUA, the National Credit Union Administration, which supervises and insures credit unions, within 72 hours of reasonably believing a reportable cyber incident has occurred. That notice goes to the regulator, not to members.

The member-facing obligation comes from elsewhere. NCUA’s rules implementing the Gramm-Leach-Bliley Act include guidance on response programs for unauthorized access to member information. It expects a credit union to notify members when misuse of their sensitive information has occurred or is reasonably possible. Banks follow parallel interagency guidance from their own regulators.

State breach laws govern notice to individuals and set their own content and timing rules. Because members live in many states, more than one law may apply. Counsel should confirm which apply. The communication plan should pre-clear message templates with counsel so that the first data statement is not drafted at two in the morning under pressure.

State law also drives the litigation clock. California’s breach notification statute requires notice in the most expedient time possible and without unreasonable delay. The California Consumer Privacy Act gives consumers a private right of action, with statutory damages, when certain personal information is exposed because a business failed to maintain reasonable security. The act’s definitions are written around for-profit businesses, so whether and how it reaches a member-owned credit union is a question for counsel. Statutory damages of this kind are one reason breach class actions in California tend to follow an attack quickly.

Notices to state attorneys general become public records. Maine’s attorney general publishes the breach notices it receives, including the number of people affected nationwide. Patelco’s counts entered the news that way. An institution should assume any count it files will be read and reported, and should file amended numbers with the same care as the first.

Getting back in: the fraud window

Restoration feels like the end of the crisis. In practice it opens a new risk, because restoration is a fraud window. A publicized outage gives criminals a ready script. They send text messages that look as if they come from the credit union, asking members to “reactivate your account” through a link. The link leads to a fake login page that captures the member’s password. This trick is called phishing, and it works best when people are expecting a message.

At the same time, when digital banking returns, thousands of members log in at once. Some reset passwords, add payees or update contact details. That is exactly what an account takeover, a criminal seizing control of someone’s account, looks like. The fraud team suddenly faces a flood of legitimate activity that resembles criminal activity.

Who bears the loss when fraud follows

The rules on fraud losses shape the institution’s incentives in the fraud window. Under Regulation E, consumers have strong protection against unauthorized electronic fund transfers, provided they report them in time. When a criminal takes over an account and moves money, the institution generally bears the loss and must investigate disputes within set time frames. A surge of takeovers after restoration therefore lands on the institution’s own books.

Scams that persuade members to send money themselves sit in a grayer zone. If a member is tricked into authorizing a payment to a fraudster, consumer protections are weaker, and recovery is harder. Member messages matter so much in the fraud window for that reason. Patelco’s guidance told members it would not ask them to move money in connection with the incident, and that fraud-check calls would only ask whether a transaction was theirs. Those two sentences close off the most common scripts.

What a re-entry plan includes

A re-entry plan treats the first weeks back as a period of higher risk. In practice:

• Every message tells members that the credit union will not send login links and will not ask for one-time codes.
• Step-up verification, an extra check such as a call-back or a code sent to a known phone number, applies to new payees, changes of phone number or email, and large transfers for a defined period.
• Fraud monitoring rules are tuned for the surge rather than switched off to cut false positives, the legitimate transactions that get flagged by mistake.
• The contact center is staffed for the backlog, because transfers and payments queued during the outage will post in bulk, and members will call about what looks like strange activity.
• A published list of known posting issues answers questions before members call.

The usual error here is to celebrate the restoration and stand down the crisis team. The best institutions keep it in place for weeks after the lights come back on.

The re-entry period also tests staff. Contact center agents who spent two weeks apologizing now face members who see unfamiliar entries, duplicate items and changed balances. They need a short script, authority to make routine fee reversals on the spot and a clear path to escalate suspected fraud. Without those, every call becomes an exception, and queues grow just as fraudsters are calling members pretending to be the credit union.

Who pays: fee relief as policy

An outage creates real costs for members: late fees from other creditors, overdrafts caused by delayed deposits, missed loan payments. These are not abstractions. For a household living paycheck to paycheck, a single late rent payment can trigger a cascade of fees.

Patelco went further than waiving its own fees. It said it would reimburse late fees members incurred elsewhere because of the outage, and offered to write letters for members whose credit was affected. Once online banking returned, it said most of its own fees would be waived automatically for July and August.

The details show how much design goes into a promise. Patelco said outside late fees for bills such as rent, utilities and other loans could be reimbursed with documentation if charged between June 29 and July 15. Members could request reimbursement through September 1. It said loan and credit card holders would not be reported as late for payments missed during the outage. It gave maturing share certificates extended grace periods and rolled them over where members could not give instructions.

Each of those commitments needed an owner and a process. Credit reporting adjustments must flow through to the credit bureaus correctly, or members find late marks months later. Third-party reimbursements need an intake form, a standard of evidence and a payment method. Certificate rollovers need a record showing why the default was applied. Promises made in a press update become operational work orders the next morning.

Those choices answer the questions every institution faces:

• Whether waivers are automatic or by request. Request-based relief floods the contact center and favors members who know to ask, often the most confident and least vulnerable.
• Which third-party fees are reimbursed, and on what evidence.
• Who drafts the letter a member gives a landlord or lender.

Data exposure adds a second layer of cost: identity protection services, such as credit monitoring, call handling for worried members and, increasingly, litigation.

Why cooperatives feel the cost differently

A credit union has no outside shareholders to absorb losses. Remediation costs, uninsured losses and legal settlements come out of earnings and net worth that belong, in effect, to the members. The NCUA treats a net worth ratio of 7 percent as the threshold for a well-capitalized credit union, and a large unplanned cost can move that ratio for a smaller institution. Generosity toward affected members is a transfer from the membership as a whole.

That creates a real tension. Automatic, broad relief is fairer and cheaper to administer, but it pays some members who suffered no loss. Request-based relief is cheaper in direct payouts and more expensive in staff time and goodwill. A board should decide where it stands on that line before an incident, with an estimate of what each approach would cost at its own scale.

These costs should be decided as policy before an incident. A board-approved remediation policy can set principles, for example that no member should be out of pocket because of an outage, and delegate amounts to management. Finance should know which costs the cyber insurance policy covers, because coverage for customer remediation, notification and legal defense often sits under different sections with different limits. The answers members get then depend on a decision made months earlier, not on who happened to answer the phone.

Insurance needs the same advance work. Cyber policies often cover forensic costs, notification and credit monitoring, legal defense and business interruption, each with its own limit and conditions. Some require the insurer’s approval before the institution hires a forensic firm or law firm. Others restrict coverage for voluntary payments to customers. Finance and risk should read the policy against the remediation policy, so that the board knows which promises are insured and which are paid from capital.

An institution that decided in advance

Pulling the four questions together, a well-prepared institution looks something like this. It has a current dependency map and has rehearsed against it. It knows which services will keep running if the core or online banking is isolated, and it has set card stand-in limits on purpose. Its status page lives outside its own network. It has two communication tracks ready, with templates already reviewed by lawyers. It has a re-entry plan for the fraud window. And its board has approved, in writing, how members will be made whole.

Contracts that set the outcome

Much of this rests on vendor contracts. A credit union’s agreements with its core, digital banking and card providers set incident notification duties, recovery time commitments, the right to see forensic findings and cooperation during restoration. They also set whether the vendor will help rebuild channels in parallel or in sequence. Those terms are negotiated at renewal, often years before an attack, by procurement and IT staff who may not be thinking about member experience.

Vendor concentration adds a further risk. In late November 2023, a ransomware attack on Ongoing Operations, a technology provider owned by Trellance, disrupted services at dozens of credit unions at once. When many institutions share a provider, an attack on that provider produces simultaneous outages, and the vendor’s capacity to restore each client becomes the constraint. Contracts should state how the vendor prioritizes clients in a mass event.

Who owns each answer, and what an examiner asks for

Ownership can be stated simply. The chief information officer owns the dependency map and recovery design. The chief information security officer owns containment, backups and the forensic engagement. Operations owns stand-in limits, posting rules and branch procedures. Marketing and member services own the two communication tracks, with counsel clearing the data track. Finance owns the remediation policy and the insurance structure, and the board approves both.

An NCUA examiner or a state regulator reviewing readiness would expect evidence. That usually means the business continuity plan and the business impact analysis behind it, recent test results with the issues found and their fixes, and backup restoration tests. Vendor due diligence files and the incident response plan with its notification procedures also belong in that evidence. The FFIEC’s business continuity management booklet, which credit union examiners also use, sets out those expectations. Many credit unions also assess their maturity with the NCUA’s Automated Cybersecurity Evaluation Toolbox.

The failures are just as recognizable:

• Treating cyber resilience as an IT project. Most of the decisions above are business and policy decisions: fees, member promises, contract terms, communication.
• Rehearsing the generic scenario. Exercises that never name a specific system and a specific number of days rarely change anything.
• Over-promising on data. Statements made before forensics are complete are the ones that come back to haunt an institution.
• Standing down too early. The restoration day is the start of the fraud window, not the end of the incident.
• Leaving relief to discretion. When fee relief depends on who calls and who answers, members are treated unequally, and that unfairness becomes part of the story.

Cheap decisions that keep getting postponed

For a financial institution, a prolonged outage touches every line a board cares about. There is direct cost: fee waivers, reimbursements, overtime, forensic investigators, identity protection. There is regulatory exposure: notice deadlines to the regulator and to individuals in multiple states. There is legal exposure. And there is trust, which for a credit union, a member-owned cooperative, is close to the whole business model.

The encouraging part of the Patelco story is that much of what shapes the member experience is within management’s control, and much of it is not expensive. A dependency map, a well-run tabletop exercise, a status page hosted elsewhere, pre-approved message templates and a board remediation policy are modest investments. They are also the investments that tend to get postponed, because in calm conditions they feel optional.

The case against planning for the member experience

A sceptic would say this puts the emphasis in the wrong place. The best member experience in a ransomware attack is no attack, so the money should go to prevention: better identity controls, faster patching, detection that catches intruders in the weeks before they strike. According to its notice, Patelco’s attackers were inside for more than a month before the outage began. Catching them then would have made the member questions moot.

Prevention deserves the larger budget, and nothing here argues otherwise. But prevention fails often enough that a regulated institution must assume it will fail once. The decisions described here cost little next to prevention programs, and they determine whether a failure becomes a two-day inconvenience or a two-week crisis. They also overlap with prevention: segmentation and offline backups slow attackers as well as speeding recovery.

A second objection is that no amount of planning helps when the attack is broad enough. If the core, the backups and the network are all compromised, every channel goes dark. The objection holds at the extreme. Most incidents fall short of the extreme, and the planning described here moves an institution further from it.

Two weeks without online banking

1. If we had to shut down online banking for two weeks starting tomorrow, what exactly would our customers be unable to do?
2. What are our card stand-in limits today, who set them, and do they let most customers buy essentials during an outage?
3. Who can approve the first public statement about data, and have our lawyers already reviewed the templates?
4. What is our plan for the first month after services come back, when fraud risk is highest?
5. Is fee relief automatic or by request, and has the board approved the policy?

With hindsight

Patelco restored online banking and its app on July 15, 2024, and brought back remaining services over the following weeks. The second half of the story, the data half, unfolded later and more painfully.

The group’s claim, as reported at the time, was that negotiations with the credit union had failed after about two weeks. Patelco did not name the attackers. The notice letters described the data involved as varying by person, including names, Social Security numbers, driver’s license numbers, dates of birth and email addresses. The two years of identity protection were offered through Experian, with an enrollment deadline in November 2024.

Two weeks after the claim, on August 29, 2024, CISA and the FBI published a joint advisory on RansomHub. It described the group as a ransomware-as-a-service operation, in which a core team rents its tools to affiliates who carry out the attacks. The advisory listed the techniques the group’s affiliates used and the defenses that would have slowed them.

On August 15 the RansomHub group, a criminal ransomware operation, claimed the attack and published stolen data. On August 20 Patelco confirmed that member and employee information had been accessed and began notifying individuals. Its filings with the Maine attorney general first counted about 726,000 affected people, later amended to about 1.01 million, and it offered two years of identity protection.

The legal consequences arrived quickly. Class actions were filed within days of the attack, and a $7.25 million class settlement received preliminary court approval in June 2025.

The service story also had a long tail. Patelco’s security update page was still being revised in March 2025, with a table of service status and answers to member questions about fees, statements and certificates. The fee reimbursement window for outside late fees had closed on September 1, 2024. For members and staff, the incident lasted many months after the systems came back.

Other events in 2024 put the case in context. On July 19, a faulty CrowdStrike software update crashed Windows systems worldwide, disrupting banks, hospitals and airlines without any attacker involved. The member experience of an outage was much the same whatever the cause, and the same dependency maps and status pages applied. Vendor concentration also remained a theme for credit unions, as the NCUA continued to press Congress for authority to examine the technology providers its institutions share.

The credit union’s own account later set out the investigation window. Unauthorized access to its databases ran from May 23 to June 29, 2024, and on August 14 it confirmed that those databases held personal information of members and employees. Because it could not determine exactly which records had been taken, it chose to notify everyone whose information was in the affected databases. Many institutions face that choice when logs are incomplete, and it helps explain why the count was so large.

Two features of the case have held up as the useful ones for other institutions.

First, the data question was answered more than six weeks after the outage began. Members, staff and the press were asking about their personal information from the first days, and the honest answer for most of that time was “we do not know yet.” Any organization that assumes it will be able to say something definitive about data in the first week is planning for a world that rarely exists.

Second, the count grew after the first filing. The number of affected people rose from roughly 726,000 to roughly 1.01 million. That is normal for forensic work, but it means every early number should be presented as provisional, and every communication plan should expect at least one update that makes the picture worse.

Together, these two facts point to a simple discipline. Institutions that plan member communication around a single announcement are planning for a sequence that does not happen. The real sequence is a series of updates over weeks and months: services first, data later, numbers revised, lawsuits and settlements after that. A board that understands this in advance can approve a communication approach, a remediation policy and an insurance structure that fit the real timeline, rather than improvising each step as it comes.