Everest Ransomware Hit Citizens Bank and Frost Bank Through a Vendor Nobody Will Name. Six Class Actions Later, Here's What Your TPRM Program Needs.

TL;DR

• In April 2026, the Everest ransomware group claimed approximately 3.65 million records from Citizens Financial Group and Frost Bank via a shared third-party vendor — a statement printing and tax document processor that neither bank has named publicly.
• Six class-action lawsuits were filed against the banks, not the vendor. Plaintiffs allege the banks failed to properly vet and constrain vendor access to customer data.
• Under the GLBA Interagency Guidelines, liability flows upstream — “our vendor was breached” describes the compromise location, not the responsible party.
• The Citizens/Frost breach is one of three major financial services vendor breaches in 2026 alone. The pattern: shared infrastructure vendors with access to sensitive data, minimal visibility into their security posture, and contracts that don’t survive the first examiner question.

On April 20, 2026, the Everest ransomware group posted Citizens Financial Group and Frost Bank on its public leak site. The claim: approximately 3.65 million records — roughly 3.4 million from Citizens and 250,000 from Frost, including Social Security numbers, tax IDs, account numbers, home addresses, mortgage interest rates, and investment data.

Both banks confirmed the breach. Both pointed to a third-party vendor. Neither named the vendor.

Within a week, six class-action lawsuits landed — against the banks. Five months later, the vendor still hasn’t been publicly identified.

If you’re running a third-party risk management program, the Citizens/Frost breach tells you something specific about what’s broken in most vendor programs: not the policy, but the operational reality behind it.

What the Everest Ransomware Group Actually Did

The Everest group is a ransomware-as-a-service (RaaS) operation that operates on a “double extortion” model: exfiltrate data first, then threaten to publish it if ransom isn’t paid. The attack on the Citizens/Frost vendor followed this pattern — the group posted sample records on its leak site as proof and set a deadline for payment.

The entry point was a shared third-party vendor handling statement printing and tax document fulfillment for both institutions. This vendor — processing 1099s, account statements, year-end tax documents — held a high-concentration data set: customer names, home addresses, account numbers, and in Frost’s case, Social Security numbers and income figures.

The core problem isn’t that a vendor was breached. Vendors get breached. The problem is that both banks’ TPRM programs apparently didn’t give them enough visibility into this vendor’s security posture to catch what was coming, and their contracts apparently didn’t give them enough leverage to respond.

SC Media’s reporting confirmed the vendor’s identity remained unknown weeks after the initial disclosure. The American Banker reporting noted that both institutions confirmed vendor involvement while declining to identify the party — a disclosure posture that may be legally defensible but is operationally revealing.

Why Liability Flows Upstream, Not Down

The first thing to understand about the Citizens/Frost breach is why the class actions were filed against the banks.

Banks regulated by federal banking agencies — the OCC, FDIC, and Federal Reserve — are governed by the Interagency Guidelines Establishing Information Security Standards rather than the FTC’s GLBA Safeguards Rule. The substantive obligations are the same: institutions must protect customer information wherever it flows, require appropriate safeguards from service providers by contract, and monitor those safeguards over the life of the relationship.

“Our vendor was breached” doesn’t discharge that obligation. It describes where the compromise occurred. The institution remains responsible for: (1) whether it adequately vetted the vendor’s security controls before onboarding; (2) whether the contract required meaningful security standards; and (3) whether ongoing monitoring gave the bank visibility into the vendor’s security posture.

If any of those three failed — and in the Citizens/Frost case, plaintiffs are alleging exactly that — the regulatory and litigation exposure lands with the institution.

The class-action theory in Citizens and Frost is not novel: customers sue the financial institution they have a relationship with, not the vendor they’ve never heard of. The plaintiffs allege the banks failed to adequately vet vendor security controls and failed to contractually constrain what the vendor could do with customer data. Whether those theories survive litigation isn’t the point. The point is that five months after the breach, both banks are defending them.

The Anonymous Vendor Problem

Neither Citizens nor Frost has disclosed the name of the vendor involved. None of the six class-action complaints has named the vendor either. This is unusual — typically, at least the plaintiff’s attorneys know who they’re dealing with — and likely reflects early-stage information asymmetry.

The ComplianceHub analysis of the breach notes that both banks confirmed the breach originated at a third-party vendor while declining to specify which one. The likely reasons: ongoing forensic investigation, contract dispute risk if named publicly, and the possibility that the vendor relationship’s scope is still being defined for regulatory disclosure purposes.

But here’s what this means for your program: if Citizens Financial Group — a $225 billion institution with dedicated third-party risk infrastructure — couldn’t prevent this, and still can’t publicly name the vendor five months later, the question isn’t whether a breach like this can happen to you. It’s whether you have enough information about your vendors to even know what you’d say if it did.

The 2026 Vendor Breach Pattern

The Citizens/Frost breach isn’t an isolated incident. It fits a 2026 pattern that is becoming impossible to ignore:

ShinyHunters breached Canada Life through Salesforce. The attack compromised customer data through the CRM vendor relationship — a different attack vector (credential-based rather than ransomware) but the same structural problem: a vendor with significant data access and insufficient security controls.

Qilin ransomware hit a UK healthcare provider through a third-party IT vendor. The National Health Service reported patient data exposure after the attack compromised a supplier’s systems that fed clinical operations.

Everest hit Citizens and Frost through a shared document processing vendor. Same RaaS group that has targeted banks and financial services institutions repeatedly in 2025-2026.

The Schneider Downs analysis of the Everest breach makes the point directly: the 2026 attacks demonstrate that shared infrastructure vendors — organizations serving multiple institutions simultaneously — are high-value targets precisely because a single breach yields data from multiple clients.

Your document printing vendor, tax fulfillment provider, statement delivery platform, or any shared-service vendor that processes data for multiple financial institutions is a target by design. Not because they’re sloppy, but because attackers have done the math.

What Your TPRM Program Actually Needs

The Citizens/Frost breach exposes five common gaps in vendor risk programs that regulatory guidance has been flagging for years.

1. Vendor tiering that reflects data access, not just operational criticality

Most fintech and bank TPRM programs tier vendors by operational criticality — would an outage stop us from operating? The Citizens/Frost breach illustrates why data access has to carry equal weight. A statement printing vendor may not be operationally critical (you could switch printers), but a vendor holding customer Social Security numbers and income data is a high-risk vendor by any reasonable definition.

If your tier-1 (Critical) vendor designation is reserved for core banking system providers, your document processing and tax fulfillment vendors may be sitting in tier-3 or lower — with annual reviews, minimal monitoring, and contract terms that haven’t been updated since 2019.

What this means: Audit your vendor tier assignments specifically for data access volume and data sensitivity. A vendor that processes fewer than 50 transactions per month but touches customer PII in bulk (statements, tax documents, correspondence) belongs in your Critical or High tier.

2. Contract requirements that survive an examiner review

The six class actions against Citizens and Frost allege the institutions failed to “contractually constrain” vendor access to customer data. This is the specific allegation — not that the breach happened, but that the banks didn’t use their contract to limit how much damage a breach could cause.

OCC Bulletin 2023-17 and the interagency third-party risk guidance are explicit on what contracts with significant vendors should include: security standards the vendor must maintain, breach notification obligations, audit rights, data minimization requirements, subcontractor oversight obligations, and exit provisions that address data return and deletion.

What to audit: Pull the contracts for your top-20 data-intensive vendors. For each one: Does the contract specify a security standard the vendor must maintain (SOC 2 Type II, ISO 27001, or equivalent)? Does it require breach notification within 72 hours? Does it give you audit rights — at minimum, the right to receive third-party audit reports on request? Does it limit how long the vendor can retain your customer data? If the answer to any of these is no, that’s a remediation gap.

See also our post on how the NYDFS Part 500 third-party guidance changes what vendor program documentation needs to include.

3. Ongoing monitoring that covers security posture, not just performance

Most vendor monitoring programs track operational metrics: uptime, SLA compliance, error rates. Very few monitor vendor security posture on an ongoing basis for non-Critical vendors.

For vendors with significant data access, ongoing security monitoring should include: annual renewal of SOC 2 or equivalent reports (with your risk team actually reading them, not just collecting them), news and dark-web monitoring for breach reports, and contractual triggers that require the vendor to notify you if their security posture materially changes.

The practical question: how would you know if your document processing vendor had a security incident six months ago? If the answer is “they’d tell us” — and your contract doesn’t require them to — that’s a gap.

4. Incident response procedures that cover vendor breach scenarios

When Citizens and Frost disclosed the breach, both were navigating notification obligations under state breach notification laws, OCC disclosure requirements, and the SEC’s Regulation S-P 72-hour notification rule (which was updated in 2024 to require breach notification clauses in service provider contracts).

Your incident response plan should include a vendor breach scenario — not just a scenario where your own systems are compromised. The vendor breach scenario should address: how you learn of a breach (monitoring vs. vendor notification), what immediate forensic steps you take, who makes the regulatory disclosure, and what your customer notification obligations are.

For more on the incident response planning requirements that regulators are testing against, see our post on CIRCIA’s final rule and what it means for financial services incident response programs.

5. Exit and data deletion documentation

The Citizens/Frost breach also highlights a question that most programs don’t have ready answers for: if you terminated a vendor today, could you confirm that customer data was returned or destroyed within a defined timeframe?

The offboarding checklist is the part most TPRM programs skip. The termination clause in most vendor contracts says the vendor will return or destroy data, but very few programs track whether that actually happened. After a breach, if a vendor is exfiltrating data your institution was supposed to have confirmed was deleted two years ago — that’s a different kind of problem.

The Examiner Question You Need to Answer Now

Seven BaaS consent orders in 2023-2026 have demonstrated that regulators are prepared to hold sponsor banks accountable for partner conduct. The Citizens/Frost breach extends that accountability principle to any vendor with data access — not just regulated partners.

If an OCC examiner walked in today and asked: “Can you show me the due diligence file for your statement printing and tax document vendors?” — what would that file contain?

If the answer is “a vendor questionnaire from three years ago and a contact name” — that’s the gap the Citizens and Frost class actions are being built around.

So What?

The Citizens/Frost breach is not primarily a cybersecurity story. It’s a procurement and contract management story. The ransomware group did what ransomware groups do. The regulatory and litigation exposure exists because the institutions’ TPRM programs apparently didn’t impose, document, and monitor the security requirements that would have (a) reduced the probability of breach, (b) given the banks faster visibility into the incident, and (c) created clearer contractual accountability when it happened.

Your TPRM program has two jobs after a breach like this: survive examiner scrutiny, and give you something to point to when a plaintiff’s attorney says “what did you do to protect our clients’ data at this vendor?”

A vendor questionnaire from three years ago in a shared folder somewhere doesn’t answer either question.

The Third-Party Risk Management (TPRM) Kit includes a vendor risk tiering methodology, due diligence questionnaire covering all 12 categories (including the 8 AI-vendor-specific questions), an ongoing monitoring template, contract review checklist, and vendor offboarding checklist. Designed around OCC Bulletin 2013-29 and the 2023 interagency guidance.

Frequently Asked Questions

Who is liable when a bank’s vendor is breached? The bank. Under the GLBA Interagency Guidelines Establishing Information Security Standards, banks are responsible for protecting customer information wherever it flows — including at vendors they retain. “Our vendor was breached” describes where the compromise occurred; it doesn’t discharge the institution’s regulatory responsibility.

What should vendor contracts include for data-intensive vendors? At minimum: a security standard the vendor must maintain (SOC 2 Type II, ISO 27001, or equivalent), a 72-hour breach notification obligation, audit rights or right to receive audit reports, data minimization and retention limits, subcontractor oversight requirements, and exit/data deletion provisions.

How should I tier my document processing and tax fulfillment vendors? By data access and sensitivity, not just operational criticality. A vendor that processes customer Social Security numbers, income data, and account information at scale is a Critical or High-tier vendor regardless of whether an outage would stop your operations. Audit your tier assignments for any vendor that handles bulk customer data.

What ongoing monitoring is expected for High-tier vendors? Annual review of SOC 2 or equivalent reports (not just collection — actual review), news monitoring and dark-web alerts for the vendor entity, and contractual triggers requiring the vendor to notify you of material security posture changes. For Critical vendors, quarterly review is the expectation under the 2023 interagency guidance.

What should my incident response plan include for vendor breaches? A specific vendor breach scenario covering: how you receive notification (monitoring vs. vendor notification), immediate forensic and containment steps, who makes regulatory disclosures, and customer notification obligations. The plan should address the SEC Regulation S-P 72-hour notification requirement that applies to incidents involving service providers.

Sources: Citizens/Frost Breach: 3.65M Records via One Vendor; Third-Party Cyber Risk in Banking: Lessons from the Everest Ransomware Claims; Citizens, Frost blame vendor after data breach claim; Customers sue Citizens, Frost over third-party data breach; Everest Ransomware’s Third-Party Breach and the GLBA Vendor Accountability Gap; Extensive Citizens Financial Group, Frost Bank breaches claimed by Everest ransomware