The Marquis Software Breach: What 80 Banks and Credit Unions Need to Learn About Vendor Concentration Risk

When breach notifications from your marketing software vendor start arriving at 80 banks and credit unions simultaneously, covering 824,000 consumers’ data—with a two-month gap between when the vendor knew and when you found out—that’s not just a cybersecurity story. That’s a third-party risk program failure at scale.

The Marquis Software breach is that story.

TL;DR

• Akira ransomware hit Marquis Software Solutions on August 14, 2025, via a SonicWall firewall vulnerability (CVE-2024-40766) that allowed attackers to bypass MFA entirely
• Marquis did not notify affected banks and credit unions until late October—more than two months post-breach; consumer notifications followed in December, nearly four months out
• The final toll: 80+ financial institutions, 824,000+ consumers, reportedly a paid ransom
• This is a textbook vendor concentration risk event: one mid-tier marketing vendor, a national blast radius, simultaneous notification and regulatory obligations across dozens of institutions
• The TPRM failures here aren’t exotic—they’re the same gaps that show up in most programs: under-tiering based on operational criticality without accounting for data sensitivity, weak contract notification requirements, and no visibility into vendor patching posture

Who Is Marquis Software and Why It Matters

Marquis Software Solutions provides data analytics, marketing, and compliance software to more than 700 banks and credit unions across the United States. If you’ve ever received a direct mail offer from your community bank, Marquis has probably had a hand in producing it. The company’s software helps institutions segment customers, run retention campaigns, comply with BSA reporting, and manage marketing data.

That description—marketing software—is the reason so many institutions under-assessed the risk. Marketing vendors don’t process payments. They don’t sit in the core banking stack. They’re not operational dependencies the way a core processor or payment network is. So they get tiered as Medium or Low risk in most TPRM frameworks.

What they do have is access to customer PII—names, Social Security numbers, dates of birth, financial account information. In many cases, they receive regular data extracts from the institution’s core systems to power their analytics. That data footprint is as sensitive as anything your core processor holds, even if the operational dependency looks different.

That’s the TPRM design flaw the Marquis breach exposed.

What Actually Happened: The Attack

On August 14, 2025, Marquis Software discovered that attackers had infiltrated its network after exploiting a critical vulnerability in its SonicWall SonicOS firewall. The vulnerability—CVE-2024-40766, an improper access control flaw—allowed the Akira ransomware group to steal VPN credentials and one-time password (OTP) seeds, effectively bypassing multi-factor authentication entirely. Patching the firewall after the fact was insufficient to stop the attack because Akira had already established persistence using the stolen credentials.

Akira is not a new actor. CISA has tracked the group extensively and documented their pattern of targeting VPN appliances at mid-size technology vendors before pivoting to the vendor’s clients. The SonicWall vulnerability they exploited had been publicly disclosed in 2024. Marquis’s failure to patch it—or to implement compensating controls that would have detected unauthorized VPN access earlier—created the initial foothold.

The stolen data included customer names, addresses, dates of birth, Social Security numbers, taxpayer identification numbers, financial account information, and bank or card details. Because Marquis received regular customer data extracts from its financial institution clients, the breach essentially exposed the consumer records of every institution whose data Marquis processed.

According to an internal email from a compliance officer at Community 1st Credit Union, Marquis paid a ransom to the attackers shortly after the August 14 discovery—despite Marquis’s public statement that there was no evidence of data misuse. The ransom payment did not prevent disclosure, but the circumstances raise obvious questions about what drove the two-month notification delay.

The Notification Failure

This is where the compliance exposure compounds.

Marquis did not notify the approximately 80 affected financial institutions until late October 2025—more than two months after the breach was discovered. Consumer breach notification letters went out in December 2025, nearly four months post-discovery.

That timeline creates real regulatory exposure.

Under the FFIEC’s computer security incident notification rule (for banks subject to OCC, Fed, or FDIC supervision), a “notification incident”—a computer-security incident that materially disrupts customer accounts or financial services—requires notifying the primary federal regulator within 36 hours. The question of whether Marquis’s breach triggered that obligation depends on how each affected institution characterizes the event. But the notification clock starts when the institution has enough information to make that determination—not when the vendor decided to disclose.

For banks and credit unions under the FTC Safeguards Rule, a security breach involving the sensitive financial information of 500 or more customers triggers a customer notification requirement. The Rule requires notification “as expeditiously as possible,” and the FTC has previously flagged two-month delays as inconsistent with that standard.

Most states have their own breach notification laws with 30- to 72-day timelines. When Marquis disclosed in late October for an August 14 breach, most of those deadlines had already passed—leaving affected institutions in an awkward position of having to notify regulators and customers about a breach they themselves didn’t know about.

If your vendor contracts don’t include a specific breach notification obligation with a defined timeline—24 to 48 hours of discovery, not “without unreasonable delay”—this scenario is the consequence.

The Concentration Risk Problem

Security researchers and examiners noted immediately that the Marquis breach was a concentration risk event, not just a vendor breach.

When a single vendor serves 700+ financial institutions and gets compromised, the blast radius is national. Every affected institution simultaneously faces:

• Regulatory notification obligations
• Consumer notification obligations
• Reputational exposure from customers receiving breach notifications attributed to their bank
• Regulatory scrutiny of their TPRM program (did you assess the vendor properly? did your contract require timely notification?)
• Internal incident response workload at the same moment every other affected institution is managing the same

One security engineer quoted in the coverage described it precisely: “A single mid-tier vendor sitting in the data flow of numerous banks can instantly create a blast radius on a national scale.”

This is not theoretical. The Synapse bankruptcy in 2024 created a similar concentration event—dozens of fintechs simultaneously losing access to a middleware layer with no prepared contingency. Marquis is the cybersecurity version of the same failure pattern.

The TPRM lesson from both events: concentration risk is a monitoring metric, not a one-time assessment. If your vendor inventory doesn’t flag when your institution shares a critical service provider with 70+ peers, your TPRM program is measuring vendor risk without measuring systemic risk.

The TPRM Failures Hidden Inside This Breach

Let’s be specific about what third-party risk practices would have changed the outcome here—not hypothetically, but based on the documented facts.

Tiering on both dimensions, not just operational criticality. Standard TPRM tiering asks: would this vendor’s outage stop our operations? Marquis would likely score Low to Medium on that question—marketing software isn’t in the payment chain. But the second question—does this vendor hold sensitive customer PII?—should trigger a higher tier regardless of operational criticality. A tiering methodology that fails to distinguish between “low operational impact, low data sensitivity” and “low operational impact, high data sensitivity” will consistently under-tier marketing, analytics, and compliance software vendors that hold the same data your core does.

Cybersecurity due diligence on the vendor’s perimeter. Supply chain cyber incidents follow predictable patterns: attackers look for vendors that are operationally indispensable to financial institutions but not subject to the same security oversight those institutions apply to themselves. Asking vendors for their patch management policy, firewall configuration standards, and VPN access controls is a standard part of due diligence for Critical and High-tier vendors. Marquis’s unpatched SonicWall firewall—a publicly known vulnerability since 2024—would not have passed a basic security questionnaire answered honestly.

Contract notification requirements with teeth. The difference between finding out about a breach in two months versus 48 hours is often the vendor contract. If your agreement says “prompt notification,” you’re at the vendor’s discretion. If it says “within 48 hours of discovering a security incident involving our customers’ data, we will notify you via email to your CISO and Chief Compliance Officer, and we will provide an initial incident report within 72 hours,” you have both a clearer obligation and evidence of vendor compliance (or non-compliance) you can act on.

Right to audit—and exercising it. Most TPRM programs include a right-to-audit clause in vendor contracts for Critical and High-tier vendors. Very few exercise it for marketing vendors. If your audit cycle for a vendor holding customer SSNs and account numbers is “SOC 2 report once a year,” you have a documentation program, not a vendor risk program.

What the Investigation Should Prompt Your Institution to Do

If you’re not one of the 80 affected institutions, this is a TPRM audit trigger, not something to read and move on from.

Pull your vendor inventory and filter for data sensitivity. Identify every vendor that receives customer PII—names, SSNs, dates of birth, financial account data—regardless of their operational tier. Treat data sensitivity as an independent variable, not a secondary factor. Any vendor holding the data Marquis held should be at minimum High-tier.

Review vendor contracts for notification provisions. Check whether your agreements with those vendors specify: (1) what constitutes a notifiable security incident, (2) the timeline for notification, (3) the required content of the initial notification, and (4) your rights if they fail to notify timely. If the answer is “none of the above,” that’s a contract renewal priority.

Review your own breach notification procedures for vendor-triggered events. Your breach notification procedures should explicitly address what happens when a vendor notifies you of a breach—not just when you discover one internally. Who decides if the event is a notification incident? What’s the decision timeline? Who drafts consumer notifications? Who files regulatory notices? These questions need answers before the call comes in.

Run the scenario with your incident response team. If a vendor calls you today and says, “We were breached three weeks ago, we’re still assessing scope, and we believe your customer data may have been involved”—what happens next? Most institutions don’t have a documented playbook for that call. Working through it now is far cheaper than figuring it out in real time.

So What?

The Marquis breach is a stress test most TPRM programs quietly failed. Not because the attack was sophisticated in a novel way—it used a known vulnerability, a known ransomware group, and a known attack vector—but because most financial institution TPRM programs don’t have a field for “does this vendor hold customer SSNs?” separate from “would this vendor’s outage stop payments?”

The practical fix is a TPRM program structure that evaluates vendor risk on two independent axes: operational criticality and data sensitivity. When both are evaluated, marketing and compliance analytics vendors land where they belong—in the tier that requires security questionnaires, contract notification provisions, and audit rights. Not the tier that gets a SOC 2 review and an annual confirmation that the relationship hasn’t changed.

Eighty banks found that out the hard way. The notification letters are still arriving.

Sources:

• Marquis breach toll rises to 80 banks, 824,000 consumers — American Banker
• Ransomware attack on Marquis Software Solutions targets 74 banks — SC Media
• Marquis Software Solutions data breach — Infosecurity Magazine
• CISA advisory: Akira Ransomware (AA24-109A)
• Vendor Risk Lessons from the Marquis Data Breach — SBS Cybersecurity