Supply Chain Cyber Incident Response for Financial Institutions: Lessons from Marquis, MOVEit, and CrowdStrike

TL;DR

• Supply chain attacks surpassed traditional intrusions as the top global cyber threat in 2026 — incidents you didn’t cause are now your most probable incident response scenario
• When Marquis Software ransomware hit 74+ banks and credit unions, exposing data for up to 1.35 million people, the affected financial institutions still owned notification obligations even though their own systems were never compromised
• The FFIEC 36-hour notification clock still runs when the breach is at your vendor; the SAR still needs to be filed; customer notification is still your obligation
• The FFIEC updated its cybersecurity guidance in 2025 — the most significant overhaul in a decade — with explicit attention to third-party cyber risk; examiners are testing this now

Your incident response plan was designed for an incident you controlled. A ransomware attack locks your servers — isolate, contain, restore. A breach hits your database — investigate, scope, notify. In either case, the affected systems are yours. You can image the servers. You can pull the logs. You can identify exactly what was accessed and when.

Marquis Software didn’t work that way.

When ransomware hit Marquis Software — a loan origination software vendor used across the community banking sector — more than 74 banks and credit unions found themselves in an incident response situation with a fundamental problem: they controlled none of the relevant evidence. They couldn’t access the affected systems. They were entirely dependent on a third party to tell them what happened to their customers’ data. Between 672,000 and 1.35 million people were affected. The financial institutions that use Marquis still owed those customers notification. They still had to analyze SAR filing obligations. They still had to run the FFIEC 36-hour notification analysis. All of it, without the ability to investigate the incident directly.

This is the supply chain incident response problem — and it’s no longer an edge case. Supply chain attacks surpassed traditional intrusions as the top global cyber threat in 2026. Three incidents — Marquis Software ransomware, the MOVEit Transfer vulnerability exploitation of 2023, and the CrowdStrike Falcon content update outage of July 2024 — represent three separate architectures of the same problem: financial institutions bearing regulatory and customer harm from incidents they didn’t cause and can’t directly investigate.

The FFIEC updated its cybersecurity guidance in 2025, described at the time as the most significant overhaul in approximately ten years, with explicit attention to third-party cyber risk. Examiners are looking at this now. Your third-party incident response track needs to exist before the vendor calls to say there’s been an incident.

Three Incidents, Three Architectures of the Same Problem

Marquis Software (2024–2025) — Ransomware targeting a loan origination software vendor cascaded across 74+ community banks and credit unions. The affected financial institutions had no direct exposure on their own networks; the breach was contained to Marquis’s systems. But Marquis processed identifiable customer data — loan applications, financial records, personal information — on behalf of those institutions. The data belonged to the banks’ customers. The notification obligation belonged to the banks. The regulatory response belonged to the banks. The data custodian had been breached; the data controllers were responsible.

MOVEit Transfer (2023) — The CL0P ransomware group exploited a zero-day vulnerability in Progress Software’s MOVEit Transfer file-transfer tool before the vulnerability was publicly disclosed. Financial institutions and their vendors that used MOVEit for large-file transfers found that attackers had exfiltrated data through the compromised tool during the window the vulnerability was open. This was different from Marquis: not a direct attack on a core banking system, but a vulnerability in widely-used shared infrastructure exploited across thousands of organizations simultaneously. Financial institutions using MOVEit directly — and those whose third-party vendors used it to move their data — both faced potential breach exposure.

CrowdStrike Falcon Update Outage (July 2024) — A defective content update to the CrowdStrike Falcon sensor triggered mass system crashes across Windows endpoints worldwide. Financial institutions running Falcon experienced extended outages — ATMs offline, trading platforms unavailable, internal operations disrupted. No data was exfiltrated. There was no attacker. The disruption was caused by software update mechanics, not malicious intrusion. But institutions whose banking services were materially disrupted still faced FFIEC 36-hour notification analysis and operational reporting obligations — for an incident that had nothing to do with security in the traditional sense.

These three cases represent the core supply chain incident types: data breach at a vendor processing your data (Marquis), vulnerability in shared infrastructure exploited across the sector (MOVEit), and operational disruption from software your systems depend on (CrowdStrike). Each requires a different response track. Each triggers overlapping regulatory obligations.

The Regulatory Clock Runs Regardless of Whose Systems Were Breached

The FFIEC computer-security incident notification rule does not have a “but it was our vendor’s fault” exception. The 36-hour notification obligation runs from when your banking organization determines that a significant computer-security incident has occurred. “Occurred at a vendor” does not pause the clock.

For Marquis-type incidents (data breach at a core vendor): the 36-hour clock starts when you determine the breach is significant — that it exposed material customer data or materially disrupted your ability to deliver banking services. You do not need to wait for the vendor’s forensic report. See the FFIEC 36-hour incident notification rule breakdown for the specific materiality thresholds.

For MOVEit-type incidents (vulnerability exploited in shared infrastructure): if you determine that data you transferred via the compromised tool was accessed, or that customer data held by a vendor using the tool was exfiltrated, you have breach notification obligations under applicable state laws — and potentially under the FTC Health Breach Notification Rule if health data was involved. Each state where affected customers reside may have independent notification requirements with its own timeline.

For CrowdStrike-type incidents (availability disruption without breach): if the disruption materially affected your banking services, the 36-hour notification obligation likely applies even without data exposure. You may not have breach notification obligations to customers if no data was involved — but you have examination documentation obligations, and potentially SAR filing if the disruption affected your ability to detect or report suspicious financial activity.

The practical implication: your incident response plan needs a notification obligation assessment that can run in parallel with the technical investigation — especially when the technical investigation is happening at a third party you don’t control. See incident triage techniques for materiality and timeline documentation for the materiality analysis framework.

Your Response Playbook: When the Vendor Calls

When a critical vendor notifies you of a security incident affecting your data or operations, the sequence differs significantly from an internal incident.

Step 1: Get Preliminary Scope in Writing — Immediately

Call the vendor. Then send an email summarizing what you were told and ask them to confirm it in writing. You need timestamped, written confirmation of:

• When the incident was discovered by the vendor
• What systems and data types were affected
• Whether data belonging to your institution or your customers is confirmed as involved
• What containment steps have been taken
• When they expect to have more information

This documentation matters because your own regulatory notification obligations may require action before the vendor’s investigation concludes. “We notified the vendor, received the following preliminary scope [attach email], and are assessing notification obligations based on available information” is a defensible regulatory position. “We were waiting for their report” usually isn’t, if the report arrives after your notification clock expired.

Step 2: Run the Notification Analysis in Parallel

Don’t wait for the vendor’s forensic report. As soon as you have enough information to make an initial assessment, work through the notification analysis:

• FFIEC 36-hour: Does this incident materially disrupt your banking services, or expose customer data at a scale that matters to the financial sector’s stability?
• SAR filing: Is there suspicious activity involving customer accounts or financial data that requires filing? The 30-day clock starts at initial detection of facts that constitute suspicious activity.
• State breach notification: Which states have customers affected? What are the applicable timelines and content requirements?
• SEC 8-K: For public company issuers — does this incident meet the materiality threshold requiring disclosure?

Document your analysis contemporaneously. Examiners reviewing a supply chain incident expect to see a materiality determination with a timestamp, not a post-hoc reconstruction.

Step 3: Preserve What You Control

You can’t image the vendor’s servers. You can document everything in your own environment:

• Logs of data transfers to and from the vendor during the incident window
• Authentication and access records for systems integrated with the vendor
• API connection logs and data volume metrics
• All vendor communications about the incident, with timestamps
• Your contractual documentation showing what data the vendor processes and under what terms

Engage your forensic firm before your internal evidence is overwritten by routine log retention policies. They may also be able to coordinate evidence collection across organizational boundaries if your contract gives you audit rights.

Step 4: Invoke Your Contractual Rights

Your vendor contract should give you the right to timely incident notification, audit documentation, and access to forensic findings when your data is involved. Invoke these in writing, immediately:

• Incident timeline documentation as it develops
• Scope confirmation for data belonging to your institution and your customers
• Remediation steps and timeline
• Evidence of cyber insurance claim initiation
• If data was exfiltrated: what data, confirmed scope, and any evidence about where it may have gone

If your contract doesn’t have these provisions, you’re negotiating the vendor’s cooperation in real time during a crisis. That’s a difficult position, and it’s the reason NYDFS Part 500 requires covered entities to include cybersecurity provisions in third-party contracts.

The NYDFS Enforcement Signal

New York’s Department of Financial Services levied $82+ million in fines in 2025, with $63.3 million in Part 500-related penalties across 2024–2025. Part 500 requires covered entities to assess the cybersecurity risks of third-party service providers, implement policies governing those relationships, and include specific cybersecurity provisions in third-party contracts.

What those enforcement actions have in common: institutions that treated third-party cyber risk as a questionnaire-at-onboarding exercise rather than an ongoing oversight program. Marquis, MOVEit, and CrowdStrike all involved broadly used vendors — vendors that many financial institutions had assessed at some point, found acceptable, and then not meaningfully re-evaluated as the threat landscape evolved.

DFS examiners are asking covered entities to show that their third-party assessments are current, that contracts include notification and audit provisions, and that incident response plans specifically address vendor-originated incidents. For non-DFS institutions, FFIEC examiners are asking similar questions through the lens of the 2025 guidance update.

What Your Third-Party Cyber Risk Program Actually Needs

The standard vendor questionnaire at onboarding didn’t prevent Marquis, MOVEit, or CrowdStrike from affecting financial institutions. A program that accounts for current supply chain risk looks different:

The most consistent gap is the tabletop. Most financial institution incident response exercises simulate an intrusion on internal systems, with the institution controlling evidence and remediation. The exercise starts with “your network was breached.” It almost never starts with “your loan origination software vendor just called to say they’ve been hit with ransomware and your customers’ data may be involved.”

That scenario exposes every gap in your notification ownership, evidence documentation approach, and regulatory coordination workflow. It’s worth running before the call is real. For institutions managing BEC incidents alongside third-party events simultaneously — a scenario that’s increasingly common when social engineering layers onto supply chain exposure — the complexity compounds.

So What?

Supply chain cyber incidents aren’t a new threat category — they’re an evolved version of the oldest one. Attackers learned that compromising one loan origination vendor is more efficient than compromising 74 banks directly. The financial sector learned this the hard way.

Three things distinguish institutions that handled these incidents effectively from those that didn’t:

First: they had a third-party incident response track that was separate from their internal IRP — with clear ownership of notification obligations when the evidence lives at a vendor.

Second: their vendor contracts had teeth — notification timelines, audit rights, and explicit data scope provisions that could be invoked immediately when an incident was reported, not negotiated in the middle of a crisis.

Third: they had already worked through their FFIEC 36-hour materiality analysis criteria before an incident hit. They weren’t determining what “material disruption” means for the first time while simultaneously assessing a Marquis notification scope.

The FFIEC updated its cybersecurity guidance in 2025. Examiners are looking at third-party risk programs with more scrutiny than they have in years. If your IRP doesn’t have a supply chain track, build it before the next Marquis. The call will come.

Sources:

• FBI Internet Crime Complaint Center (IC3) 2025 Annual Report
• FinCEN Ransomware Resources for Financial Institutions
• FFIEC Cybersecurity Resource Center
• NYDFS Cybersecurity Regulation 23 NYCRR Part 500
• CISA Advisory: MOVEit Transfer Critical Vulnerability

The Incident Response & Breach Notification Kit includes templates for third-party incident response coordination, FFIEC 36-hour notification documentation, SAR filing timelines, and materiality analysis worksheets — built for incidents where the breach isn’t on your systems.