Lucas Hathaway
If you work at a credit union, the last few months have made one thing hard to ignore: your next incident probably will not start on your network. It will start at a vendor. When a major industry vendor gets breached, the credit unions we talk to all go through the same sequence: lost trust, hard questions from the board, a scramble to figure out what data was exposed, and a plan to never be caught flat again.
The teams that handle it well are not smarter. They have a playbook. This post gives you one.
Quick answer: When a critical vendor is breached, verify the notification and demand specifics, activate your incident response plan with the vendor breach playbook, determine what of your data was in scope, decide on member notification, report to the NCUA within 72 hours if the incident meets the reporting threshold, reclassify the vendor's risk rating, and decide with documentation whether to stay or exit. Then run a tabletop on the exact scenario so the next one is muscle memory.
Don't Risk Vendor Breaches
Get AI-Powered Vendor Security Reviews
Why a vendor breach needs its own playbook
Your incident response plan probably assumes you control the environment. In a vendor breach you control almost nothing. You cannot pull logs, you cannot contain, and you often cannot even get a straight answer about what happened. The vendor's lawyers are writing the notifications, and their timeline is not your timeline.
What you do control is your side: your data map, your members, your regulator, and your decision about the relationship. A vendor breach playbook is the document that keeps those four things moving while the vendor sorts out theirs. If your current IR plan has one generic playbook for "breach," build this one next. If you want to get granular, we have seen teams build a dedicated playbook for their one or two most critical vendors, like the core system. That is a good use of an afternoon.
Two more reasons this moved up the priority list. First, examiners are already there: a CISO on our March panel described his most recent NCUA exam and named third-party due diligence as a top focus, with examiners asking what he is really doing to understand what his third parties are doing. Second, the breach that hits you may not even be your vendor. It can be your vendor's vendor, a fourth party you have never assessed, which is exactly why the playbook below starts with verification rather than assumptions about who was breached and what they owe you.
Step 1: Verify and demand specifics
The first notice you get will be vague. Sometimes you find out from the news before you hear from the vendor at all, which is its own finding for your vendor management program.
Get the account manager and the vendor's security contact on a call and ask for specifics in writing: what systems were affected, what data types, the date range, whether your institution's data was in scope, and their remediation timeline. If your contract has a notification clause, this is the moment it earns its keep. If it does not, note that for renewal. We recommend every critical vendor contract require notification within a defined window and ongoing investigation updates, so you are not six months behind the story.
Step 2: Activate your plan, even though it is not your breach
Treat the notification as an incident trigger. Convene the same incident response team you would for an internal event: security, IT, compliance, communications, legal, and an executive sponsor. Assign an incident commander. Start a timeline log on day one, because your examiners will ask for it later and your insurer might too.
The instinct is to wait for the vendor to tell you more. Do not wait. Everything in steps 3 through 6 can start with the information you already have.
Step 3: Determine your data exposure
Pull the vendor's record from your vendor inventory and your risk assessment. What data types does this vendor store or process for you, and roughly how many member records? If you cannot answer that in an hour, that gap is the real lesson of the incident.
This is also where the dollar conversation starts. A vendor holding 50,000 member records with Social Security numbers is not a "high risk" label. It is a quantifiable exposure: records at risk, times a defensible cost per record from published breach data, adjusted for likelihood. When the CEO asks how bad this could be, "high" is not an answer. A dollar range is.
Step 4: Decide on member notification
Notification depends on what was actually exposed, your state requirements, and the vendor's own notification plans. Coordinate rather than duplicate: members who get two confusing letters trust you less than members who get one clear one. Legal counsel drives the requirement; your communications lead drives the tone. Draft the member FAQ and the frontline staff script now, before the call volume starts, because your member service team will hear about this breach whether or not you send a letter.
Step 5: Report to the NCUA
Under the NCUA's cyber incident reporting rule, federally insured credit unions must report a reportable cyber incident within 72 hours of reasonably believing one has occurred, and that includes incidents at third parties that affect your members or operations. The bar for reporting is lower than most teams assume, and the call is short. When in doubt, report. Examiners have been consistent on this point: they would rather hear about a near miss than find an unreported incident in your files.
Document who made the reporting decision, when, and on what basis. That one paragraph in your incident log saves a long exam conversation later.
Step 6: Reclassify the vendor and re-review
A breached critical vendor does not keep its old risk rating. Move it to your highest tier, shorten its review cycle, and re-run the security review against what the breach revealed. The SOC 2 you filed last year described the program that just failed, so read the bridge letter and the incident report, not just the old audit.
While you are in there, fix the point-in-time problem that let the risk drift in the first place. A question we got on our July panel put it well: annual reviews are snapshots, so what signals tell you a vendor's risk profile changed between them? Two are worth standing up now. Watch your own traffic for new destinations or new behavior from the vendor's product, and treat any change in the vendor's use case or feature set, including a quietly added AI capability, as a trigger for re-review rather than a note for next year's file.
This is where Rivial Software changes the speed of the response. Clients keep their vendor inventory, data classifications, and reviews in one place, so pulling the exposure picture takes minutes instead of days. The AI-powered vendor review can re-assess the vendor's updated SOC report against your own control set the day you receive it, and the vendor's risk rolls up into your risk assessment in dollars, so the board sees exactly what this relationship is worth and what it now costs in exposure.
Step 7: Decide whether to stay, and write it down
Some breaches end relationships. Most do not, because switching a core vendor is a multi-year project and the honest math often favors staying with stronger controls and contract terms. Either answer is defensible. An undocumented answer is not. Record who made the call, the criteria, the compensating controls or contract changes you required, and the date you will revisit it.
Step 8: Run the tabletop before the next one
Take this exact scenario and make it a tabletop exercise this year: a critical vendor is breached, member data may be in scope, the news breaks before the vendor notifies you. Walk the room through steps 1 through 7. Who calls the vendor, who drafts member communication, who owns the NCUA report, at what point does insurance get involved. You do not need the vendor in the room. You need your own people to know their roles before the day it is real.
The key is simple: the playbook you test is the playbook that works. The one you wrote and filed is just a document.
Don't Risk Vendor Breaches
Get AI-Powered Vendor Security Reviews