When you’re relying on lots of other services in your technology stack, you need to have a plan for what to do if the company offering that service shuts down. Software escrow — which is the practice of depositing the source code of that service with a third-party — can be a crucial part of this business continuity planning.
Wayne Scott, regulatory compliance solutions lead at Escode, joined the most recent episode of our podcast, Get With IT, to talk more about software escrow contracts.
Here is an edited and abridged version of that conversation:
David Rubinstein, editor-in-chief of ITOps Times: What do you mean by software escrow? And how does that work?
WS: It’s not a new concept. It’s been around since about 1984 or so, developed simultaneously in the UK and the US by two separate companies initially. The idea is to ensure continuity of service, particularly revolving around the three risks of supplier failure, service deterioration, and concentration risk. Companies will fail, we’re all very familiar with our favorite shops going out of business when we walk down the High Street.
And yet, we have this faith that our favorite and our most critical software services will be continually available. But every tech company, every supplier, every particular piece of software is subject to market forces. So an escrow solution in itself is the idea of establishing a legal right to access the information required to carry on using those services, could be source code, or access credentials, or spun down fresh instances of multi-tenanted services. Then you’ll do a sort of knowledge transfer, you’ll get the people who own the information to show you how to use it and essentially develop a build manual on how to rebuild the application from the source code. And then finally, a scenario test. The idea is to be able to bring the management of a failed service in-house or pass the management to another. What you’ve got to do is test the ability of whoever is going to be receiving what’s stored underneath the escrow agreement to actually deal with it and rebuild that service. Can they follow that instruction manual? Or can they buy the things on that shopping list?
DR: And I know this is all around operational resilience as well, which is certainly not new. But in today’s complex world, where things are changing so rapidly, new technologies are being developed, and new methodologies are being used, how difficult is it for companies to maintain compliance with regulations and things that will keep them going?
WS: It’s a really good question because these regulations now are coming thick and fast. They’re coming from all over the place. Certainly, the UK and Singapore lead the way within financial services when it comes to operational resilience regulation, on the heels of Canada, Switzerland and the Digital Operational Resilience Act in Europe. The US regulations are a little further behind on this one. But, you know, I was over New York recently, and there’s been some very clear indication from the Financial Services regulators over there that it’s coming. We don’t know what it is or what it’s going to look like. But there’s been expressed admiration for the way that Europe and the UK are doing these things.
To answer your question, though, it’s not hard to accommodate as long as you’ve thought about it. And then that’s where the issues can lie. You may have heard terms being bandied about sort of like security by design, or resilience by design. This is basically just building all your services with your own failure in mind. You know, if we don’t exist any longer, if this company doesn’t exist, if I don’t work at this company, what information would be required to be able to manage this service, to rebuild the service going forward? Is this repeatable? Have I documented this? Is that hardware openly available on the open market anymore? These fourth party tools or third party tools that are involved here, can they be procured?
It’s sort of the opposite of the tech company mentality really. Instead of “there is no room for failure,” well, I mean, there is room for failure. I’ve worked for a couple of failed tech companies, I’ve run a failed tech company. But if you start with the idea of your own failure in mind, the idea then is to build out a sort of set of controls to limit the other damage that can be caused by your own failure. Tech companies fail all the time, the fintechs, 90% of them will fail in a first year.
DR: So one of the things I wanted to ask you about also is, I know that you guys recently did a third party risk management survey. What were some of the key findings there? Was there anything that surprised you within the data that came out?
WS: Across three different regions, we looked at the UK, Europe, and the US. We split it into those categories because the UK regulations within financial services are older, Europe’s then followed, and then the US is yet to fully embrace these kinds of regulatory changes. These regulations look for the building of contingency plans, exit plans, plans to cope with supplier failure, and they need to be successful, you need to be able to prove that they work.
And what we certainly saw was a high level of confidence that these plans will be completed and fully working by the deadline of March next year. And yet, little progress had been made towards completing and then following on from a lack of understanding of the ownership of the risks when it comes to SaaS services. When it comes to supplier failure of services that are SaaS services, the ownership of those risks actually sits with the end user.
And the vast majority of the third party risk management experts that we surveyed weren’t aware that they had to have plans to mitigate those risks. When we went even further into it, we then found they weren’t fully aware of, if you like, the buck stopping with the C suite. You know, the ultimate owner actually being somebody very seriously high up internally. What we also saw from all of these financial institutions globally, when approaching their suppliers, they were getting pushback from them saying that it’s not in your contract, you’re gonna need to amend your contract for us to do this. And they weren’t aware of the regulations. So we need to be educated around it.
And then each of the suppliers were then objecting to being defined as material or business critical when they don’t really get to make that decision. The end user makes that decision. And then we’re getting proportionality objections. In other words, cost objections were being thrown up across the board. Yes, you can have one of these stressed exit plans or contingency plans, but it’s going to cost you. What frequently led to this is that maybe the service needs completely redesigning, or it just was not technically possible. All of these big financial institutions and smaller financial institutions were highly confident they were going to meet these deadlines, meeting objections across the board, and being faced with more than one supplier admitting that it couldn’t technically be accommodated.
In theory, it may mean that the services that were being supplied to the financial institutions weren’t resilient. Now, that’s kind of a big deal when you’re dealing with financial services and financial services regulators, and can be costly. If you’ve ever sat down and redesigned an entire service, it can be costly. It takes some time and sometimes it’s not possible. So, you know, by identifying those kinds of objections, you know, at a bare minimum, it allows the financial institutions to make a much more informed decision on whether to own the risk of continued usage of that service. But some of them will need to move away. Now, that’s why suppliers need to know about these regulatory changes as early as possible because they are spreading out slowly into the verticals and other markets as well.
You may also like…
Q&A: Is nuclear energy the key to meeting the demands of AI workloads?
