Your Vendor Had a Cyber Incident. Now What?

If a vendor you rely on has a cyber incident, your first job is finding out exactly what data or systems of yours that vendor could reach. Don’t wait for an official notification letter to start looking. Most community banks and credit unions in Montana don’t have a documented answer to that question until an examiner asks for one.

This is not a rare scenario. Third-party vendors have become one of the more common paths attackers use to reach a financial institution, because it is often easier to compromise a vendor with weaker controls than to attack a well-defended bank or credit union directly. That is exactly why examiners have started paying closer attention to how institutions manage vendor risk, not just how well they defend their own network.

What Counts as a “Vendor Incident”

A vendor incident is not limited to your core processor. Any third party with access to your data, network, or customer information can put you at risk if it gets compromised. That includes:

• Core banking or lending platform providers
• Software vendors with remote access to your systems, including help desk tools, monitoring agents, and browser plugins
• Payment processors and any payment-adjacent service
• Marketing platforms, HR systems, and document-management tools that store customer or employee data
• Managed service providers or IT contractors who hold administrative credentials

If any of these has a breach, a ransomware event, or an unauthorized access incident, you inherit the fallout. You did not cause it and you cannot control how the vendor responds, but your customers, your regulators, and your board will still expect answers from you.

Your First 48 Hours

The first two days after you learn about a vendor incident set the tone for everything that follows.

1. Confirm exactly what access the vendor actually has to your environment. Don’t rely on what you assume it has; pull the real permissions, integrations, and data-sharing agreements.
2. Check your own systems and logs for unusual activity connected to that vendor, including new logins, data transfers, or account changes you did not authorize.
3. Loop in leadership and your board liaison early. Waiting for the vendor’s full incident report before you say anything internally almost always costs you time you did not need to lose.
4. Write down what happened and when you found out. That timeline becomes the record you will need later, both for your own board and for an examiner.
5. Don’t assume the vendor’s notification timeline matches your own regulatory obligations. Your customer notification and reporting deadlines may already be running, whether or not the vendor has told you everything yet.

The Question Examiners Ask (That Most Institutions Can’t Answer)

After a vendor incident, examiners typically ask for one specific thing: your vendor risk assessment for that vendor, dated and current. A general vendor management policy describing your overall approach does not answer that question. What they want is a document tied to this vendor, updated recently enough to reflect the relationship as it exists today.

We call this gap tools versus proof. You may already run vendor due diligence, but if you cannot produce the specific assessment on short notice, the exam treats that control as functionally absent. A policy sitting untouched in a shared drive for two years will not hold up in that conversation.

Where Vendor Risk Fits Into Your Broader Security Program

Vendor risk rarely shows up as a single line item on a checklist. It sits alongside access reviews, backup testing, and incident response planning as one of several areas examiners now expect institutions to document and prove, not just assert. A strong password policy will not help you if a vendor with broad access to your systems gets compromised.

Our Advanced Cybersecurity and Compliance program treats vendor risk as one thread in that larger picture, alongside monitoring, access control, and documented incident response, so the evidence an examiner asks for is already organized before the request comes in. If wire transfers are part of what a compromised vendor could reach, our companion piece on business email compromise covers the specific verification habits that stop wire fraud, whether the attacker is impersonating a vendor or an executive. For credit union readers, our NCUA IT Requirements guide covers how vendor and payment-processor risk assessments fit into NCUA’s named 2026 supervisory priorities in more detail.

Reducing Vendor Risk Before It’s a Problem

The best time to build your vendor risk documentation is before you need it.

• Tier your vendors by access level and data sensitivity, then set a review cadence that matches the tier. Your core processor and any vendor with administrative access deserve an annual review at minimum; lower-risk vendors can go longer between checks.
• Build vendor risk language directly into new contracts. Breach notification timelines, right-to-audit clauses, and clear data-handling requirements give you leverage if something does go wrong later.
• Keep a simple evidence file for each critical vendor: the assessment itself, the relevant contract terms, and the date you last checked in. When an examiner or your board asks, you want to pull that file in minutes, not weeks.
• Ask new vendors for their own security certifications and incident history before you sign, not after a problem surfaces.

Frequently Asked Questions

What is vendor cyber risk?
Vendor cyber risk is the exposure your organization carries because a third party, such as a software provider, processor, or service vendor, has access to your systems or data. If that vendor is compromised, your institution can be affected even though the breach did not originate on your own network.

How often should a bank or credit union review vendor risk?
At minimum, annually for vendors with access to sensitive systems or data, and more frequently for your highest-risk, highest-access vendors. Reviews should be dated and documented, not just discussed at a meeting.

What is the difference between a vendor risk assessment and a security audit?
A vendor risk assessment evaluates the risk a third party introduces to your organization: their access, their controls, their track record. A security audit examines your own environment. Both matter, but examiners typically ask for the vendor risk assessment specifically when a vendor incident occurs.

Who is responsible for vendor risk at a small institution?
Ownership usually falls to whoever manages IT or compliance day to day, but the board holds ultimate accountability. Naming a specific owner, even at a small institution, keeps the review from becoming a once-a-year scramble.