11 min read
Credit Union Cybersecurity: Beyond the Basics
In August 2025, a ransomware gang breached Marquis Software Solutions through an unpatched SonicWall firewall and stole the personal data of 1.3...
In this article:
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:
- 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.
- 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.
- 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?
- 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?
- 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.
Is Your Security Posture Ready for Vendor Risk?
ABT's Security Grade Assessment evaluates your Microsoft 365 configuration against a financial services security baseline. When your vendors get breached, your own security controls are the last line of defense.
Get Your Security GradeFrequently Asked Questions
What was the Marquis Software breach and how many financial institutions were affected?
The Marquis Software breach occurred in August 2025 when attackers exploited an unpatched SonicWall firewall vulnerability to deploy ransomware. Marquis provides marketing and compliance software to over 700 financial institutions. The breach exposed data on 823,548 consumers across 80 banks and credit unions, including Social Security numbers, account numbers, and dates of birth.
What is vendor risk management for financial institutions?
Vendor risk management for financial institutions is the process of identifying, assessing, and monitoring risks introduced by third-party service providers. FFIEC, NCUA, and OCC guidance requires financial institutions to perform due diligence before engaging vendors, maintain ongoing monitoring, and hold vendors accountable for protecting customer data. The institution remains responsible for vendor failures.
What should financial institutions require from software vendors regarding cybersecurity?
Financial institutions should require SOC 2 Type II attestation, documented vulnerability management programs with patching service-level agreements (SLAs), incident response plans with notification timelines, data encryption details for at rest and in transit, and contractual provisions for breach notification, right to audit, and liability. Annual review of these materials is a regulatory expectation.
Is a financial institution liable when a vendor gets breached?
Financial institutions bear regulatory responsibility for protecting customer data regardless of where that data is stored or processed. When a vendor is breached, the institution must manage customer notifications, regulatory reporting, and remediation. Examiners evaluate whether the institution performed adequate vendor due diligence and had appropriate contractual protections in place.
How does the Marquis breach affect NCUA and FFIEC examination expectations?
The Marquis breach reinforces examiner focus on third-party risk management during NCUA and FFIEC examinations. Examiners will likely increase scrutiny of vendor due diligence programs, especially for vendors that handle customer PII. Institutions should expect detailed questions about vendor security assessments, ongoing monitoring practices, and incident response plans covering third-party breach scenarios.
What Microsoft 365 Conditional Access and DLP configurations help mitigate vendor breach exposure?
Financial institutions should configure Conditional Access policies that restrict third-party vendor access to specific applications and data, enforce multi-factor authentication for all external connections, and block legacy authentication protocols that vendors may use for integrations. Data Loss Prevention (DLP) rules should monitor and restrict the flow of customer personally identifiable information to vendor systems, flagging unusual data export patterns. Sensitivity labels on documents containing customer data prevent unauthorized sharing even if a vendor's environment is compromised. DMARC email authentication prevents attackers from spoofing your domain during vendor breach response communications.
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). |
