The Peril of Supplier Bankruptcy: Are You Exposed to Silicon Valley Bank's Failure?

The failure of Silicon Valley Bank has got me thinking about a risk modelling factor that is a perennial favourite of mine, but one that I’ve found largely gets ignored when I try and get engagement on it.

Namely, any supplier that you deal with has a non-zero chance of going bankrupt – and what’s the effect on you when they do?

I think the reason why no one ever engages with this issue is that losing a supplier to bankruptcy a) something of a “crossing the Rubicon” event (it either happens or not, but when it does it’s huge), and b) the only way to deal with the risk is to create redundancy, and that’s egregiously difficult to do. It’s a risk that’s very easy to put into the “deal with it when it happens” bucket.

If you imagine a business that owns all its own servers, has perpetual licensing, has staff on payroll that knows how to maintain it, houses it all in its own building, and has its own connectivity, all the factors related to the continued life of the IT system running on that fabric are all under your control. If someone digs up the road outside and cuts through the only leased line connecting your business to the world – that’s on you.

As we have moved to the cloud, what has happened is the workloads have remained roughly the same, but we have outsourced the fabric on which we run those workloads. We have done this in broad terms to transform large capital expenditure into smaller operational expenditure. Over time, the cost remains the same – it’s an issue of capitalisation. In reality, some of the costs increase when multiplied over the months and years we keep those solutions in place for, but there is some value paid back for that extra cost, particularly around reliability.

The benefit for the suppliers in selling cloud solutions is that rather than a “feast or famine” cashflow as customers do or do not spend money in large lumps, cashflow for suppliers is smoothed out through monthly payments. For the supplier, this is fantastic as if you have a bunch of customers all spending money with you each month on a subscription basis, it’s becomes quite difficult for that business to be killed as the risk is so effectively spread.

The problem is that from the customer side, because everything is being outsourced on a monthly basis, the unavoidable risk is that the supplier goes bankrupt and your system is cut-off. Back in the old, on-premises world, this almost couldn’t happen. It goes back to that old joke that “the cloud is just someone else’s computer” – if it’s your computer, there are very few risks that cannot be solved with a quite Saturday afternoon, some pizzas, the boot of a Ford Mondeo, and some creative thinking.

Imagine if you will that you’re a £50m manufacturing business, and your Dynamics ERP runs in the cloud, by which I mean they own the servers and co-locate them in a data centre inside the M25 that happens to be owned by a US company. That US company banks with Silicon Valley Bank, but can’t access the cash needed to pay its bills and now that data centre has no electricity, no connectivity, and all the staff are at home on LinkedIn looking for a new job. What do you do now?

Now, your ERP system is running on a bunch of computers that are sitting in a deathly quiet, dark, and cold data centre in Slough. You no longer have a business – and you better hope your business continuity planning had a parallel cloud system ready to switch over to.

As I started at the top of this article, for me this is always such a major risk point I don’t understand why more people do not engage with it. There’s always a risk that any supplier you deal with will go under, even without a proto-banking crisis popping up without warning in the world’s largest economy.

The answer is that you do need to model these risks properly. If you have a key business system that is just one month away from total unavailability, you do either need a mirror system available for immediate failover, or you do need to be supremely confident that you can build a new one from a backup. What you can’t do is ignore it.

By Matthew Reynolds