It was a tough week for the banking industry, but especially community banking. Two names most consumers have never heard of landed on breach lists this week. Jack Henry and IDScan.net. Neither one is a bank. Add LexisNexis, still working back from an August intrusion, and you have three companies that aren’t banks and are every community bank’s problem.
That gap is the story. Follow any one of these far enough and you end up at a company your bank has never heard of, holding something that belongs to your customers.
What happened
Jack Henry, the core provider behind more than 7,000 financial institutions, got hit through a vishing call. Attackers talked employees out of credentials, reached a non-production corporate environment, and took customer information tied to fewer than ten client institutions. The company was given a payment deadline and publicly refused to pay.
IDScan.net is an identity verification vendor whose technology sits behind Jack Henry and a number of other products. A dark web listing advertising more than 150 million driver’s license scans has been traced to it. The FBI is investigating. IDScan hasn’t confirmed the source.
LexisNexis detected an intrusion on August 17 and pulled Diligence, Newsdesk, and its Metabase API offline. Diligence is the platform compliance teams use for background and due diligence checks. It was the second LexisNexis incident this year.
Read the LexisNexis detail again. The intrusion was on servers hosted and managed by a third-party vendor. A vendor of theirs. Still not named publicly.
Your bank didn’t choose any of these companies
Ask a community bank CFO how the core provider got selected and you get a real answer. There was a committee. There was a demo. Somebody negotiated the contract.
Ask the same question about IDScan and there’s nothing to tell you. IDScan came with Jack Henry. LexisNexis came with the KYC obligation your examiner expects you to meet. The bank inherited both.
That’s what makes vendor risk in community banking different from vendor risk anywhere else. A regional retailer picks its own stack. A $900M bank buys a core platform and inherits a supply chain assembled by someone else, for someone else’s reasons, years before anyone at your bank signed anything.
Your exposure didn’t come from a decision you made. It came attached to one.
Count the tiers
Pull your vendor inventory. It’s organized around companies you hold contracts with. Names, criticality ratings, a SOC 2 report in a folder, a review date.
Not one of these failures respected it.
Jack Henry is tier one for most banks. Named, contracted, SOC 2 on file, review date on the calendar. None of that stopped the call from working. The incident started on a phone call, with an employee you can’t audit, in an environment you’ll never see. Your 200-question assessment asks whether security awareness training exists. It does exist. It existed on the day of the call.
IDScan is a different problem. It probably isn’t on your list at all, because you never chose it. It reached your customers’ identity documents by sitting inside a product you bought, not because your bank bought it directly.
The LexisNexis outage is the third version. LexisNexis itself is likely tier one too, tracked, SOC 2 in the folder. But the outage traces to a company that doesn’t appear in anyone’s inventory at any tier: a hosting provider for a vendor whose name you know. From your seat, it has no name at all.
Concentration risk is the piece banks underrate most. When 7,000 institutions run on the same core, an incident there is a sector event with 7,000 separate disclosure decisions attached. Regulators understand this. FFIEC guidance has addressed subservice providers for years. Most vendor programs still stop at tier one, because tier two is hard and nobody asks for it at the exam.
Nobody asks until they do.
The half of this nobody writes about
Two of these were data incidents. The LexisNexis one was mostly an outage, and outages are the underrated half of vendor risk.
Diligence went dark. If your compliance team runs enhanced due diligence or adverse media checks through that platform, the workflow stopped. Not because your bank had an incident. Because someone else did.
Your business continuity plan covers your systems. Ask what it says about a compliance tool you don’t host, can’t restore, and can’t get a restoration estimate for. Most plans say nothing, because the plan was written around servers instead of dependencies.
Four things worth doing
None of these require a new tool.
Get the subservice list. Your core contract almost certainly entitles you to know which providers it depends on. Ask for it in writing. If the answer comes back slow or vague, that’s information too.
Read the complementary user entity controls in the SOC 2 you already have. That section tells you what the vendor assumes you’re doing on your side. It’s the most skipped page in the report and the one an examiner will point at after an incident.
Put notification terms in the contract. How fast they tell you, in what form, and who at your bank they call. Contract language with teeth beats a clean report.
Name the manual fallback for every critical vendor workflow. If your due diligence platform is down for six days, what does the compliance team do on day two. Write it down before you need it.
The uncomfortable part
None of that would have prevented anything that happened here. It isn’t prevention. It decides whether you hear about it from your provider or from a reporter, and whether your team knows what to do in the hours after the call.
You can’t secure a vendor you didn’t select and can’t audit. You can know its name before something goes wrong.
Most banks don’t have that list. Building it takes an afternoon, and it’s the most useful afternoon your vendor program will spend this year. If you want help building it, book a call: https://cal.com/vaughn-cyber-group
