What the Marquis Breach Teaches Financial Institutions About Vendor Risk

In June 2024, one vendor shut down 15,000 car dealerships across America. CDK Global — the software platform that ran their operations — got hit with ransomware. Dealers couldn't sell cars, process loans, or look up service records. For three weeks. That wasn't a dealership security failure. It was a supply chain failure.

Eight months later, the same pattern hit financial services. In August 2025, attackers breached Marquis Software Solutions — a compliance platform used by over 700 banks and credit unions — through a vulnerability in SonicWall's cloud backup system. Not a vulnerability in Marquis. Not in the financial institutions. In the vendor's vendor. Eighty institutions affected. Over 824,000 consumers exposed. And the breach didn't happen at any of them.

The Verizon 2025 Data Breach Investigations Report confirms this isn't an outlier. Thirty percent of confirmed breaches now involve third-party vendors — doubled year-over-year from 15 percent. The Snowflake breach cascade in 2024 followed the same pattern: 165 organizations compromised through a single platform, including Santander Bank and AT&T.

When Marquis filed a federal lawsuit against SonicWall in February 2026, the complaint laid out exactly what happened. Marquis had the firewall patched. MFA was enabled. Their security controls were in place. But SonicWall introduced a vulnerability into a system that Marquis's customers never even knew existed. That's not third-party risk. That's fourth-party risk — and almost no financial institution is managing it.

Vendor risk management is the process of identifying, assessing, and monitoring the security risks that third-party providers introduce to your environment. For financial institutions, it's a regulatory requirement, not a best practice. But most vendor risk programs stop at the first layer. The Marquis breach proves that's not enough.

What Happened With the Marquis Breach

Marquis Software Solutions provides marketing automation, compliance document generation, and member communication tools to community banks and credit unions. They sit in a privileged position: their software handles customer PII (personally identifiable information), account data, and regulatory communications.

Attackers gained entry through a known SonicWall firewall vulnerability, accessing Marquis systems on August 14, 2025, and deploying ransomware. Compromised data included names, Social Security numbers, dates of birth, financial account numbers, and driver's license numbers.

Eighty financial institutions confirmed affected. Over 823,000 consumers had data exposed. Individual institutions are now sending breach notification letters, offering credit monitoring services, and preparing for regulatory examination questions about their vendor risk management programs.

Among the affected: dozens of community banks and credit unions across multiple states — recognizable names in the financial services space. Individual institutions are now navigating breach notification requirements, offering credit monitoring, and fielding questions from their own examiners about vendor oversight.

Why Vendor Risk Is Different for Financial Institutions

Every industry has vendor relationships. Financial institutions have vendor relationships with regulatory consequences.

Your Examiner Holds You Responsible

FFIEC (Federal Financial Institutions Examination Council), NCUA (National Credit Union Administration), and OCC (Office of the Comptroller of the Currency) examination guidance is explicit: the financial institution is responsible for managing risks introduced by third-party relationships. Your vendor's breach is your regulatory problem. The examiner won't accept "our vendor got hacked" as a sufficient answer. They'll ask what due diligence you performed before engaging the vendor, what ongoing monitoring you had in place, and what your incident response plan says about third-party breaches.

The NCUA examination process specifically evaluates how credit unions manage external dependency risk. Vendor risk management is a scored domain, not an afterthought.

The Data Is More Sensitive

When a marketing software vendor for a retail company gets breached, the exposed data might include email addresses and purchase history. When a marketing software vendor for financial institutions gets breached, the exposed data includes Social Security numbers, account numbers, and financial records. The regulatory notification requirements are different. The potential for identity theft and financial fraud is different. The reputational impact on a community institution that serves a local market is different.

The Concentration Risk Is Real

Marquis serves over 700 financial institutions. A single breach at one vendor affected 80 of them simultaneously. That's concentration risk at the industry level. When your vendor serves hundreds of institutions like yours, a single security failure at that vendor creates cascading consequences across the financial services sector.

What Went Wrong and What It Reveals

An unpatched firewall vulnerability caused the Marquis breach. This is not a sophisticated nation-state attack. It's a known vulnerability in a network appliance that didn't get patched in time.

That fact should concern every financial institution that uses Marquis or any vendor with similar infrastructure. It raises specific questions:

• Did your vendor due diligence include infrastructure security assessment? Asking a vendor if they have a firewall is not vendor risk management. Asking how they manage firewall patching, what their vulnerability management cadence is, and whether they have monitoring for known CVEs (Common Vulnerabilities and Exposures) is vendor risk management.
• Did your vendor provide a SOC 2 Type II report? A SOC 2 attestation would have evaluated the vendor's change management and vulnerability management controls over a sustained period. If the vendor had one, the auditors should have examined their patching practices. If they didn't have one, that's a gap your due diligence should have flagged.
• Did your vendor notify you promptly? The breach occurred in August 2025. Notifications to affected consumers extended into February 2026. The timeline between breach, discovery, investigation, and notification matters for your incident response obligations.
• Did your incident response plan cover third-party breaches? Most financial institution incident response plans focus on breaches within the institution's own environment. A provider that understands financial services builds incident response plans that include vendor breach scenarios with specific escalation paths and regulatory notification procedures.

Vendor Due Diligence That Actually Works

The FFIEC's guidance on third-party relationships provides a framework. Here's what that framework looks like in practice for IT and software vendors:

Before You Engage

• SOC 2 Type II attestation. This is the minimum. Type II covers a period of operation, not just a point-in-time check. Ask for the report and read the exceptions, not just the opinion letter.
• Vulnerability management program documentation. How does the vendor manage patching for their infrastructure? What is their SLA for critical vulnerability remediation? The Marquis breach happened through an unpatched firewall. That question would have surfaced the gap.
• Incident response plan review. Not just "do they have one?" but does it include customer notification timelines, data preservation procedures, and cooperation with regulatory investigations?
• Data handling and encryption. Where is your customer data stored? How is it encrypted at rest and in transit? Who has access? What are the retention and destruction policies?

Ongoing Monitoring

• Annual SOC 2 report review. Not "collect the report and file it." Read the report. Look for control exceptions. Compare year-over-year changes.
• Security questionnaire updates. At minimum annually. Include questions about changes to infrastructure, personnel, subcontractors, and security incidents since the last review.
• Breach notification monitoring. Track public breach disclosures for your vendors. Services like HaveIBeenBreached, state attorney general databases, and industry intelligence sharing networks can surface vendor incidents before the vendor tells you directly.
• Contract provisions. Right to audit clauses, breach notification timelines, liability provisions, and data return/destruction requirements. These need to be in the contract before you need them.

What Your Institution Should Do Now

Whether or not you use Marquis Software specifically, the Marquis breach is a catalyst to evaluate your vendor risk management program:

1. Inventory your vendors that touch customer data. Not just core banking and LOS (loan origination system). Marketing platforms, document management, print/mail vendors, analytics tools. Any system that processes, stores, or transmits customer PII is in scope.
2. Review your due diligence files. For each data-touching vendor, do you have a current SOC 2 report? A completed security questionnaire? Evidence of their vulnerability management and incident response programs? If the answer is no for any vendor, that's an immediate action item.
3. Test your incident response plan against a vendor breach scenario. Walk through it. The vendor calls and says they've been breached. Your customer data was exposed. What do you do in the first hour? The first day? When do you notify your regulator? When do you notify affected customers?
4. Assess concentration risk. How many of your critical vendors serve a large portion of the financial services industry? If one of them gets breached, what's your exposure? Do you have contingency plans for vendor disruption?
5. Ensure your managed IT provider is part of the solution. Your IT provider should be helping you monitor vendor security posture, maintain due diligence documentation, and build incident response plans that cover third-party scenarios. If they're not involved in your vendor risk management program, you have a gap.

Frequently Asked Questions

Technical Reference

The following tables define the regulatory frameworks and technical terms referenced throughout this article.

Regulatory Frameworks

Term	Full Name	What It Means
FFIEC	Federal Financial Institutions Examination Council	The interagency body that writes the IT and vendor management examination standards used by NCUA, OCC, and FDIC examiners.
NCUA	National Credit Union Administration	The federal regulator that charters and examines federally insured credit unions.
OCC	Office of the Comptroller of the Currency	The federal regulator that charters and examines national banks and federal savings associations.
FTC Safeguards Rule	Federal Trade Commission Standards for Safeguarding Customer Information	The updated FTC regulation requiring non-bank financial institutions (including mortgage companies) to implement comprehensive information security programs, including vendor risk management.

Glossary

Term	Definition
Conditional Access	Microsoft Entra ID policies that enforce login requirements — such as multi-factor authentication, device compliance, and location restrictions — before granting access to Microsoft 365 resources.
CVE	Common Vulnerabilities and Exposures — a standardized catalog of publicly disclosed security vulnerabilities, each assigned a unique identifier used across the cybersecurity industry.
DLP (Data Loss Prevention)	Microsoft Purview rules that detect and block sharing of sensitive data — such as Social Security numbers, account numbers, and loan data — outside the organization.
DMARC	Domain-based Message Authentication, Reporting, and Conformance — an email authentication standard that prevents attackers from spoofing your organization's email domain.
PII	Personally Identifiable Information — data that can identify an individual, including Social Security numbers, dates of birth, account numbers, and financial records.
SLA	Service-Level Agreement — a contractual commitment specifying the level of service a vendor must provide, including response times, uptime guarantees, and remediation timelines.
SOC 2 Type II	An independent audit verifying that a service provider's security controls are designed properly and operating effectively over a sustained period (typically 6-12 months).