This is part two of “A Tale of Concentration Risk”, which started with Dan‘s phone not working the way he wanted it to.  Part Two is not a rant. It is a vow, as The Banana Strikes Back!!

This past Monday morning, everybody who had committed to the Apple ecosystem had to stop what they were doing, to apply updates before starting their week, in order to remain safe.  

Not me.

I had a rare on-site meeting to leave for, very early that morning.   When I first saw the announcement in our updates channel – before my first cup of coffee – flashbacks of the morning I almost missed giving my talk arose.  I muttered, “the ghost of  Steven Jobs has ordered us to update.”

But I had prepared for this, the day I ordered a Fitbit to replace the Apple Watch that’s 15% off in my step count.  That was a couple of weeks ago, after I counted steps to a thousand 3 times.  Since then, I registered my Speaker’s Laptop, and made sure I could log into our systems from it.

So after the first Monday morning cup of java, I grabbed my Windows laptop, after powering down all of my Apple devices.   I showed up to that meeting on time, and safely logged into our system.   My laptop didn’t look as cool, but it worked. 

I now have a banana ecosystem.   Whatever it takes, loyalty to productivity, not vendor. 

—-

But what is Vendor Management, Really?

We can make jokes, we can complain, we can whine and cry.  But inherent risk is inherent risk.  None of those reactions control that risk.  It’s concentration risk, and we should apply the controls we have available to manage that risk.

Vendor management is a process we have been standing up since the early days of the iPhone, and most of the controls we use in vendor management are SUPPOSED to address concentration risk, though they don’t work very well with ecosystems.

And that includes the ecosystem created by a community bank’s core processor.

—

Concentration Risk Mitigation Tactics:

Depending too heavily on a single vendor or a small number of vendors for critical services or products is inherent in the above-named Big Bells, we should consider the actual impact of such risk. Normally, concentration risk leads to disruptions and vulnerabilities if the vendor faces issues like financial instability, supply chain disruptions, or cybersecurity breaches.  But aside from cybersecurity breaches, for which risk is usually transferred from the vendor back to the customer, by the way, these impacts do not usually materialize with the big bells.  They’re not going out of business, and they own the entire supply chain.  The big bells simply represent financial and strategic risk.  Other people have written about their suspicious EOL and price strategies. 

So this article has value, let’s still discuss what we CAN do about concentration risk in vendor management.  There are seven things we are ALREADY DOING, that normally mitigate concentration risk, if we’re banks or if we’re complying with a security framework or standard that includes vendor management.  Let’s walk through these seven things in light of the Big Bell concentration risk.

Concentration Risk Controls

Vendor Diversification:  The frustrating part about the big bells is that they’ve rendered this control useless.  We’re not going to use Open Office no matter how much Microsoft reads our email.   But maybe we use Slack as our primary communication platform, and have Teams as the platform for third parties.  Platform segregation does not hurt security, and it’s a way to be less reliant on Microsoft.  How core retires people.

Vendor Assessment and Selection Practices:  Normally a vendor would be subject to a due diligence process.  We’d require four promises.  We’d require information about recent breaches.  We’d ask questions about “the five precepts” – assurance, insurance, financial viability, contractual terms, business continuity. 

But we ask these questions because our vendors, if they want our business, will answer them.  We know if we request actions on the part of the vendor in our selection process, the vendor will act. 

Not true for the big bells. 

We take what we can get with the big bells.  But then when we do look at the assurance and such we’re reminded that deep pockets do the right thing to avoid legal risk, take a deep breath, and bypass almost all controls surrounding the vendor.  When was the last time your auditor asked you for your search and selection paper trail justifying your decision to stay with Microsoft operating system?  When was the last time you compared Microsoft with Apple with Unix with Android? 

Are you worried your auditor is going to ask you why you are not considering Google’s Fuschia? 

The take-it-or-leave-it approach, at least for small businesses and community banks, should at least put us in a position where we do NOT have to perform all checklist items for these type of vendors.  If there can be no actionable results from the assessment, let’s just reflect the risk as high and move on.  Please note: your examiner or auditor may not agree with this, but you should at least pose it to them.

Contractual Agreements:  Another concentration risk mitigator is structure contracts to include clauses that mitigate concentration risk, such as the right to audit, data protection agreements, and service level agreements (SLAs).  Who cares if you’re putting all your eggs in one basket, if that basket is woven from the finest weeds and your contract gives you plenty of ways out.  I’d WANT to put all my eggs in a basket that was kept in a safe place and was willing to work with all my other baskets.  This is what we strive for in our relationship with their core providers.  We certainly won’t get it from the Big Bells.

Regular Monitoring and Review:  This concentration risk control should be built into the notion that we have a cyclical vendor management program in the first place.   There are now plenty of vendor management software alternatives available to track performance metrics, audit results, and compliance status.  But is this a worthwhile activity for the big bells? 

Business Continuity and Disaster Recovery Planning:  Again, it’s nice to know what we’re already doing addresses concentration risk.  But maybe we should consider adding a column to our business impact analysis that helps us identify those assets that do fall into the concentration risk category.  If asset a is available from only one vendor, we may decide to abandon the recovery of asset a’s dependency, and implement workarounds, until the only vendor available has offered the only solution available.   This would apply even with the big bells, and our core providers. 

Risk Transfer:  Finally, a control that covers both big bells, core processors, and normal vendors.  We use insurance and contractual indemnities, along with outsourcing, to transfer some of the financial risks associated with vendor failures.  This is even more important with concentration risk.  How the rubber meets the road on this, maybe it could be a rider with the insurance policy that lowers the deductible for Vendor A.  Or better yet:  business interruption insurance to cover the cost of Office 365 becoming Office 360.   Or the Core Processor having a huge security breach. 

Exit Strategies:  In 2010, four years after vendor management guidance was published for banks, when we started seeing the adoption of cloud technologies proliferate, we realized the wisdom of developing a termination plan for cloud providers.  We cheered when we saw the OCC add this as an additional requirement beyond the FFIEC guidance in their infamous OCC Bulletin 2013-29.  Of course, we winced when we realized they wanted their banks to apply it to ALL vendors, not just cloud vendors.  And I actually asked an OCC examiner one time, “Under what conditions would you expect [this bank] to fire Microsoft?” 

Unlike the OCC examiner who wanted a single-location Client of mine to review Google’s financial statements, this examiner smiled and said I was making a good point, and agreed that termination plans can be based on risk.  But the examiner would not go so far as to agree it can be based on the likelihood of action.  That was around 2015 or so, but I suspect the resistance to “likelihood of action” remains with some of our regulators.

—

Can’t you see?

Weirdly, on the way to that Monday morning meeting, having started the apple update that ended up taking two hours, I decided to listen to the radio.  The song by The Marshall Tucker Band was playing. 

I am grateful that I finally stepped out of whatever perspective I was locked into, that perspective that caused me to commit to any “vendor ecosystem.” 

But more importantly, I have renewed empathy for our Clients, who are locked into the ecosystems created by their core processor.   Nobody needs to remind them of the concentration risk they face from their core contracts.  Their core providers remind them of it daily.

Our Clients suffer due to that commitment, just like I suffered from my commitment to the Apple Ecosystem. 

But they can’t escape it, like I just did. 

Will we still use Microsoft operating systems?  iPhones or Google phones?  Of course.  But we can and should apply concentration risk mitigators whenever possible.

According to my grandpa, Ma Bell provided great service back in the 20s and 30s, before becoming a monopoly.   But long before I was born their service started eroding.  By the time I was taught how to use a phone in the third grade, not only was Ma Bell notorious for bad service, but you had no choice but to use them.

Banks need to be looking for ways to dilute their concentration risk at every corner.  Maybe it should be an annual duty.

I love music.  You can tell that by now in this post, as I hope you’re starting to understand my cryptic allusions to 1970’s pop culture.  The allusions stopped when I began articulating concentration risk because this is serious stuff for our Clients.

‘Cause I must admit, if I did have unearned loyalty to Apple when I made the ecosystem commitment, it was because of all the cool things I could do MUSICALLY with my apple devices. 

Not very productive.  (Unless you consider bliss to be productive.)

The Banana Strikes Back

I’m not done buying Apple devices.   They still kick-butt musically 

But I am done committing to any of the 2024 Big Bells.  If Microsoft is Ma Bell, then Apple is Pa Bell.  We can call Google “Aunt Bell,” and Facebook the “Creepy Uncle Bell.”   (And let’s face it. TikTok would then be the redheaded stepchild.)

These companies broke the Internet.

And I’m really starting to rethink our architecture plan.  Do we really want to get so far in bed with Ma Bell that we would call her Azure?

At a minimum, going forward, I will at least check my loyalty at the door of “no-choice.”  I will try to find small companies to productively and safely handle my information processing needs.  In other words, I will remain as committed to any of these bells as they are to their customers. 

Notta. 

Alleluia (Leonard Cohen Version)